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RESUMO 


O framework i* é uma linguagem dedicada à Engenharia de Requisitos. Hoje, a 
comunidade que desenvolve i* é relativamente grande e esses desenvolvedores, 
que estão geograficamente dispersos, tendem a atribuir diferentes significados 
para os construtos de sua linguagem. Argumenta-se que essa flexibilidade é 
parte da própria natureza do framework, e de fato pode ser considerada uma de 
suas características-chave de sucesso. Mas, por outro lado, é nossa convicção 
de que isso representa uma barreira em termos de promoção do framework, 
criando sérios problemas, tais como: a) dificuldade na comunicação eficiente 
de conhecimento entre os especialistas da comunidade; b) aumento da curva 
de aprendizado dos recém-chegados; c) inibição da adoção do framework por 
profissionais da indústria; e d) interoperabilidade sintática e semântica existente 
em vários dialetos. Nos últimos anos, a comunidade tornou-se ciente do problema 
e várias tentativas foram feitas para facilitar o acesso e uso uniforme da linguagem 
i*. Apesar de reconhecer que há resultados significativos nessa direção, essas 
tentativas não são bem sucedidas na resolução dos problemas mencionados 
anteriormente, simplesmente porque as abordagens propostas são puramente 
sintáticas, sem dar atenção à semântica dos conceitos da linguagem. Indo além 
de questões sintáticas, desde 2006, pesquisadores estão envolvidos em uma 
tentativa de definir uma ontologia comum, com o objetivo de fornecer a semântica 
para os principais conceitos da linguagem i*. Com isso, é possível propor uma 
série de diretrizes de modelagem, aqui chamadas diretrizes ontológicas, que 
apoiam o modelador no uso dos construtos da linguagem. Nesta dissertação, 
apresentamos um estudo empírico para validar as diretrizes ontológicas. Para 
isso, propõe-se um experimento em um ambiente controlado no qual se comparam 
modelos preenchidos por dois grupos: um utilizando as diretrizes ontológicas, e 
outro sem qualquer conhecimento de tais diretrizes. Resultados demonstram que, 
para modeladores mais experientes, as diretrizes efetivamente representam um 
ganho, provendo modelos de maior qualidade. Já para modeladores iniciantes, 
os resultados não se mostram igualmente promissores. Com base nos resultados 
dos experimentos, esta dissertação propõe, ainda, a criação de um plugin que dê 
suporte a modeladores iniciantes na construção de modelos i* compatíveis com 
as diretrizes ontológicas, fazendo com que, pouco a pouco, o modelador aprenda 
e se torne mais autônomo no uso de tais diretrizes. Esse apoio se dá na interação 
por meio de um diálogo entre plugin e modelador, fazendo com que as diretrizes 
ontológicas sejam úteis na prática da construção de modelos j*. 


PALAVRAS-CHAVE: ;*, estudo empírico, Ontologia, UFO, diretrizes de modelagem. 


ABSTRACT 


The i* framework is a Requirements Engineering language. Today, the community 
developing i*is relatively big. These developers, who are geographically dispersed, 
tend to attribute different meanings to /* constructs of the language. One may argue 
that due to the social intention behind ;* modeling, a certain degree of freedom is 
convenient and these slight changes should be acceptable. But on the other hand, 
itis our belief that this represents a barrier in terms of promoting the framework, 
creating serious problems, such as: a) difficulty in efficient communication among 
the community's experts; b) increase in the language's learning curve by novices; 
and c) lack of acceptance by industry; and d) syntactic interoperability and existing 
semantics in various dialects. In the past few years, the community became aware 
of this problem and several attempts have been made to create a uniform use of 
the i* language. Although we recognize there are significant results in this direction, 
these attempts are not successful to solve the aforementioned problems, simply 
because these approaches are purely syntactical, not targeting the semantics 
behind the language's concepts. Going beyond syntactic questions, since 2006, 
researchers have been involved in an effort to define a common ontology to provide 
the semantics to the core concepts of |”. As a result of this approach, it is possible 
to provide a series of modeling guidelines, here named ontological guidelines, to 
support the modeler in the use of the i* constructs. In this dissertation, we present an 
empirical study created to validate the ontological guidelines. For that, we propose 
an experiment made in a controlled environment, in which ;* models are completed 
by two groups: one using the ontological guidelines and the other that does not 
have any contact with such guidelines. Results show that for more experienced 
conceptual modelers, the guidelines effectively represent a gain in providing higher 
quality models. For beginners in conceptual modelers, however, results are not 
equally promising. Based on the results of the experiments, this dissertation also 
proposes the creation of a plugin that supports modelers beginners in building 
i * models compatible with the ontological guidelines, so that, little by little, the 
modeler learn and become more autonomous in the use of such guidelines. This 
support occurs in the interaction through a dialogue between plugin and modeler, 
causing the ontological guidelines are useful in the practice of building models / * 


KEYWORDS: |”, study empirical, Ontologies, UFO, modeling of Guidelines. 
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CAPÍTULO 1 
INTRODUÇÃO 


Este capítulo descreve a motivação do desenvolvimento da dissertação; a seção 1.2 
descrevem os objetivos pretendidos para a realização da pesquisa; a seção 1.3 apresenta a 
metodologia utilizada para a realização do trabalho; e por fim, a seção 1.4 descreve como a 
dissertação está estruturada. 


1.1 MOTIVAÇÃO 


me 


* é uma linguagem dedicada à Engenharia de Requisitos (ER), fase inicial do 
desenvolvimento de software, que trata do levantamento, modelagem, verificação e 
especificação dos requisitos de um sistema. Para Yu (1997), a ER está recebendo cada 
vez mais atenção, por considerar que a fase inicial do ciclo de vida de desenvolvimento de 
sistema é fundamental para o desenvolvimento e implantação do sistema. 

O framework i* possui uma estrutura conceitual capaz de reconhecer motivações, 
intenções e raciocínio sobre as características de um processo, o que facilita os esforços 
nas atividades de ER (Yu, 2001). Nos últimos vinte anos, i* vem atraindo a atenção de 
diversos grupos de pesquisa, que formam, portanto, uma comunidade de desenvolvedores 
dessa linguagem. Esses grupos de pesquisa estão geograficamente dispersos e tendem 
a atribuir diferentes significados para os conceitos da linguagem. Argumenta-se que essa 
flexibilidade é parte da própria natureza do framework, e de fato pode ser considerada 
uma de suas características-chave de sucesso. Mas, por outro lado, é nossa convicção 
de que isso representa uma barreira em termos de promoção do framework, criando 
sérios problemas, tais como: a) dificuldade na comunicação eficiente de conhecimento 
entre os especialistas da comunidade; b) aumento da curva de aprendizado dos recém- 
chegados; c) inibição da adoção do framework por profissionais da indústria; e d) problema 
da interoperabilidade sintática e semântica. 

Nos últimos anos, a comunidade tornou-se ciente do problema e várias tentativas 
foram feitas para facilitar o acesso e uso uniforme da linguagem i*. Uma dessas iniciativas 
é a criação de um repositório comum e um ambiente de colaboração para a comunidade, 
chamada Wiki i*. Em particular, no wiki, há uma seção chamada diretrizes, que objetiva 
reunir diferentes abordagens da linguagem, provendo orientações aos modeladores 
quanto ao uso dos elementos de i*. Trabalhos em metamodelagem também buscam deixar 
claro o significado dos elementos distintos da linguagem (Amyot et al,. 2009), (Susi et al., 
2005),(Lucena et al., 2008). Apesar de reconhecer progresso o valor dessas iniciativas, 
argumentamos que elas não provêm uma solução para interoperabilidade, porque os 
metamodelos são estruturas poderosas para definir a sintaxe de uma linguagem, porém 
não são capazes de deixar clara a semântica por traz dos construtos da linguagem. Cares 


1. http://istar.rwth-aachen.de/tiki-view. articles.php 
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(2012) propôs um método de interoperabilidade que considera um supermetamodelo, que 
facilita a tradução de uma variante de i* para a outra. Ele propõe ainda uma linguagem 
baseada em XML, denominada iStarML, para dar apoio à interoperabilidade das ferramentas 
de apoio a i*. Essa abordagem avançou o estado da arte, provendo um formato padrão de 
interoperabilidade que facilita a tradução de modelos. Por outro lado, iStarML promove 
apenas verificações sintáticas, não fornecendo apoio à interoperabilidade semântica. 

Guizzardi et al. (2012, 2013) vão além da sintática, propondo uma ontologia comum 
para os conceitos de i*. A partir dessa ontologia, propõe-se uma série de diretrizes de 
modelagens, aqui chamadas diretrizes ontológicas, que apoiam o modelador no uso 
dos construtos da linguagem. Esses pesquisadores propuseram tais diretrizes, mas 
não realizaram sua validação, para determinar se elas efetivamente produzem ganhos, 
auxiliando o modelador na escolha dos elementos de modelagem e gerando modelos i* de 
melhor qualidade. 

Para que as diretrizes ontológicas possam fazer a diferença efetiva na prática da 
construção de modelos i*, um protótipo é proposto para auxiliar os modeladores iniciantes 
no desenvolvimento de modelos i*, fornecendo as orientações e a liberdade de modelagem. 
Sendo útil no aprendizado para modeladores iniciantes conforme a criação do modelo, 
além de auxiliar os desenvolvedores mais experientes através da validação do modelo, 
depois de desenvolvido, de acordo com as diretrizes ontológicas. 

Nesta dissertação, propõe-se uma validação de tais diretrizes ontológicas, baseado 
em um estudo empírico em ambiente controlado. Atualmente, estudos empíricos são 
considerados meios apropriados para provar a eficácia de uma nova abordagem. Para 
Vokac (2002), a ciência ideal teria um conjunto de observações empíricas para cada teoria, 
para apoiar ou descartar tal teoria. Em outras palavras, a experimentação está no centro do 
processo científico, já que é a partir de experimentos que se pode checar teorias, explorar 
fatores críticos e compreender novos fenômenos para que uma teoria possa evoluir 
(Travassos, 2002). 


1.2 OBJETIVOS 


Esta dissertação tem como objetivo geral aplicar um experimento para validar 
as diretrizes ontológicas desenvolvidas por Guizzardi, Franch, Guizzardi e Wieringa, 
e desenvolver um protótipo de um plugin para auxiliar os modeladores iniciantes na 
construção de modelos i* seguindo as diretrizes ontológicas apresentadas no capítulo 3. 
Esse objetivo geral pode ser detalhado nos seguintes objetivos específicos: 


* Analisar se Os participantes são capazes de utilizar as diretrizes ontológicas 
para criar modelos i*; 


* Analisar se as diretrizes ontológicas facilitam a escolha pelo elemento ou rela- 
ção correta, no desenvolvimento de modelos i*; 
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Demonstrar qual a percepção dos participantes sobre a utilidade das diretrizes 
ontológicas; 


Analisar o tempo de desenvolvimento dos modelos i*, com o uso ou não das 
diretrizes ontológicas; 


Desenvolver um protótipo de um plugin para auxiliar os modeladores iniciantes 
no desenvolvimento de modelos |*. 


1.3 METODOLOGIA DE DESENVOLVIMENTO DO TRABALHO 


Este trabalho surgiu com a necessidade de validar as diretrizes ontológicas 


desenvolvidas por Guizzardi et al. (2012, 2013). Para atingir o objetivo geral e específicos 


listados na seção 1.2, os seguintes passos foram realizados: 


Passo 1. Foram feitos levantamentos de informações a respeito do tema da 
dissertação, por exemplo, sobre a linguagem i*, sobre o uso de ontologias para 
prover semântica dos conceitos de linguagens de modelagem conceitual e so- 
bre estudos empíricos. Essas informações foram pesquisadas no portal de pe- 
riódicos da CAPES, Domínio Público e bibliotecas digitais das Universidades 
Federais, bem como em máquina de busca, por exemplo: (i) Google Scholar; 
(ii) IEEExplore; (iii) Scopus; (iv) ACM Digital Library; (v) Springer; (vi) Sage Jour- 
nals . Informações estas encontradas em dissertações, teses, jornais, artigos 
científicos, congressos, revistas especializadas e materiais disponibilizados 
pela orientadora. 


Passo 2. Já com a compreensão do tema de pesquisa, o próximo passo foi 
projetar o experimento de validação das diretrizes, definindo-se: (i) design do 
experimento; (ii) tipo de experimento; (iii) forma de análise dos dados; (iv) o 
número de participantes. 


Passo 3. Já com o experimento projetado, o próximo passo foi criar todos os 
documentos necessários para realizar o experimento: (i) questionário do perfil 
do participante; (ii) questionário de atividades; (iii) questionário de avaliação das 
atividades; (iv) slides de apresentação de i* e das diretrizes ontológicas. 


Passo 4. Após o experimento aplicado, o próximo passo foi fazer as análises 
dos resultados para chegar a uma determinada conclusão que responde os 
objetivos específicos definidos nesta dissertação e validar as nossas hipóteses. 


Passo 5. Por fim, coube-nos relatar, nesta dissertação, os resultados da pes- 
quisa realizada. 


1.4 ORGANIZAÇÃO DO TRABALHO 


O restante desta dissertação está organizado da seguinte forma: 


O Capítulo 2 descreve a revisão da literatura correspondente à dissertação aqui 
apresentada, apresentando i*, discutindo sobre ontologia e, mais especifica- 
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mente, a ontologia UFO, utilizada na definição das diretrizes ontológicas e, por 
fim, descrevendo uma abordagem para a realização de experimentos; 


O Capítulo 3 trata das diretrizes ontológicas para a criação de modelos i*. Nes- 
se contexto, o capítulo aborda os principais dialetos da linguagem, descreve 
a metodologia utilizada para realizar a análise ontológica, além de realizar a 
interpretação ontológica dos conceitos relacionados aos elementos e links de i*. 


O Capítulo 4 apresenta a parte principal da dissertação, descrevendo o experi- 
mento aplicado e analisando seus resultados. 


O capítulo 5 propõe formas de suporte automatizado utilizando as diretrizes on- 
tológicas. Para isso, apresenta um metamodelo de i*, desenvolvido compatível 
com as diretrizes ontológicas e propõe a criação de um plugin para construção 
de modelos baseado em um diálogo com o modelador. 


O Capítulo 6 apresenta a conclusão do trabalho desenvolvido, juntamente com 
as contribuições e trabalhos futuros. 
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CAPÍTULO 2 
REFERENCIAL TEÓRICO 


Este capítulo tem como principal objetivo apresentar a teoria de fundamentação para 
a realização desta dissertação; a seção 2.1 descreve sobre i* Star; a seção 2.2 introduz 
conceitos sobre Ontologias; a seção 2.3 faz uma abordagem sobre estudos empíricos; 
finalmente a sessão 2.4 traz as considerações finais do capítulo. 


2.1 —- i* STAR 


Istar é uma linguagem utilizada na primeira fase de modelagem de um sistema, 
sendo útil para compreender o problema do domínio em questão. De acordo com (Wiki 
1), a linguagem de modelagem i* permite modelar, tantas situações “as-is”! e “to-be”. O 
nome i* refere-se à intencionalidade e é uma abordagem desenvolvida para modelagem 
e raciocínio sobre ambientes organizacionais. Seu sistema de informação é composto 
por diferentes atores e muitas vezes concorrentes. Entende-se por ator em i* um termo 
genérico, no qual, os Agentes referem-se a agentes físicos, Role é um ator abstrato que 
desempenha um papel, por último Posição é uma coleção de funções que são cobertas 
por um agente físico. Em i* (Yu, 2001), o construtor central da modelagem é a intenção do 
ator, no qual possuem propriedades intencionais, como, objetivos, crenças, habilidades e 
compromissos. 

O framework * possui uma estrutura conceitual capaz de reconhecer motivações, 
intenções e raciocínios sobre as características de um processo, o que facilita os esforços 
nas atividades de ER. Os modelos i* oferecem uma série de níveis de análises, em termos 
de capacidades, funcionalidades, viabilidade e credibilidade (Yu, 2001). 

Lembrando o leitor que existem muitos dialetos da linguagem i*, podendo haver 
algumas variações nas notações apresentadas a seguir. 


2.1.1 Modelo Estratégico Dependência (SD) 


Modelo Estratégico Dependência (SD), é usado para expressar uma rede de 
relacionamentos intencionais, estratégicas entre atores. Os diagramas SD mostram as 
dependências estratégicas entre atores, mas não retrata o raciocínio interno por trás dessas 
dependências (wiki |”). Ou seja, um conjunto de nós e links, onde cada nó representa um 
ator e cada ligação entre dois atores indica que um ator depende do outro para algo, a 
fim de que o primeiro atinja o objetivo. De acordo com Yu (1995), o modelo descreve um 
processo em termos de relações de dependências entre os agentes intencionais. Em outras 
palavras, agentes dependem uns dos outros para os objetivos serem alcançados, as tarefas 
a serem executadas e os recursos serem fornecidos. Para Santos (2008), SD fornece 
uma descrição intencional do processo em termos de uma rede de relacionamentos de 
dependência entre os atores relevantes. SD fornece um importante nível de abstração para 


1. Optamos por não traduzir alguns termos em inglês, por encontrar em sua maior parte, referência escrita em inglês. 
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descrever sistemas em relação aos seus ambientes, em termo de relações intencionais 
entre eles (Yu, 2001). Portanto, permite o modelador mesmo sem conhecer os objetivos e 
as crenças de uma organização ou sistemas, consigam compreender e fazer a sua análise. 
O modelo SD é utilizado na Engenharia de Requisitos para identificar os relacionamentos 
entre atores de um determinado setor ou setores diferentes, com o intuito de as motivações 
e intenções por trás das atividades e fluxo em um processo ou atividade. 

Os modelos SD têm como objetivo capturar as motivações e os desejos dos atores 
que fazem parte de um grupo, no qual, fazem parte de um relacionamento. Para Yu (1995), 
o modelo SD visa captar as motivações subjacentes e as intenções por trás das atividades 
visíveis em um processo próprio. Através de um modelo SD identificamos a viabilidade ou 
não das dependências, também existem as capacidades de relacionarem os desejos de 
um ator com as habilidades do ator do qual ele depende. Portanto, cada relacionamento 
capturado em |* é uma dependência chamada dependum entre dois atores, um é o depender 
e o outro é o dependee. O primeiro acontece quando o ator depende de outro ator, que 
nesse caso é o dependee, para que o acordo chamado dependum possa ser realizado. 

Os relacionamentos de dependência usados em i* são divididos em 4 categorias, 
sendo elas: (i) tarefa; (ii) recurso; (iii) objetivo; por último (iv) softgoal. (Por exemplo, 
o depender depende de um recurso do dependee para alcançar o objetivo, em outras 
palavras, João depende da impressora de Maria para imprimir os seus documentos). Os 
modelos SD são automaticamente caracterizados por adaptar os conceitos intencionais, 
como objetivo, crença, capacidade e compromisso, desenvolvido para modelagem de 
agentes em inteligência artificial (Yu, 1995). A Tabela 2.1, mostra a sintaxe e conceitos dos 
elementos pertencentes ao modelo SD. 


Tabela 2.1 — Sintaxe e conceitos dos elementos pertencentes ao modelo SD. 


Sintaxe Definição 


Ator é uma entidade ativa que realiza ações 
para atingir um objetivo. Por exemplo, 
Pessoa. Para Yu (2001), Atores são 
autônomos e não são totalmente possíveis de 
serem conhecidos ou controláveis. 


Papel é caracterizado pelo comportamento de 
um Ator social dentro de um contexto, suas 
características são facilmente transferíveis 
para outros atores sociais. Por exemplo, uma 
pessoa dentro de uma empresa pode ter um 
papel de diretor. De acordo com (Wiki |”), 
peso o conceito de Papel é uma caracterização 

abstrata do comportamento de um ator social 
de um contexto ou domínio qualquer. 


Papel 
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Agente 


Agente é um ator com manifestações físicas 
concretas, como um indivíduo humano ou 
artificial, como agentes hardware e software. 
Conforme Yu (1995), as suas características 
não são facilmente transferidas para outras 
pessoas. Por exemplo, suas habilidades. 


Depend 


” 
= 


Dependencia 
de Objetivo 


Dependência de objetivo ocorre quando 

o depender depende do dependee para 
alcançar um determinado objetivo, não 
importando a forma que esse objetivo é 
alcançado. Por exemplo, João tem como 
objetivo imprimir seus documentos, mas para 
isso ele depende de Maria para que seus 
documentos sejam impressos. Conforme 
(Wiki i*), Dependência de objetivo, ocorre 
quando o depender depende do dependee 
para trazer um certo estado de coisas no 
mundo. 


Depend 


” 
q 


Dependência 
de Tarefa 


Dependência de Tarefa ocorre quando o 
dependee é solicitado para executar uma 
tarefa. Entenda-se por tarefa, a forma de 
realizar algo ou uma atividade. Por exemplo, 
Maria tem como tarefa, imprimir o documento 
de João. Para (Wiki |”), Dependência de 
Tarefa, ocorre quando o depender depende 
do dependee para realizar uma atividade. 


Dependência 
de Recurso 


Depend 
ee 


Dependência de Recurso ocorre quando 

o depender depende de alguma entidade 
física ou informação disponível. Por 
exemplo, para pagar um boleto bancário, é 
necessário saber do valor a ser pago. Esse 
valor é caracterizado como um recurso 
informacional. De acordo com (Wiki |), ao 
estabelecer essa dependência, o depender 
ganha a habilidade de usar essa entidade 
como um recurso. 


Depend 


EL] 
= 


Dependência 
de Softgoal 


Depend 
ee 


Dependência Softgoal ocorre de forma 
similar com a Dependência de objetivo, ou 
seja, representa um desejo de satisfazer o 
objetivo, mas não possui um critério claro 
para verificar se o objetivo foi alcançado. 
Para Yu (1995), Dependência Softgoal é 
quando um Depender depende do Dependee 
para realizar alguma tarefa que encontra um 
softgoal. 


AFigura 2.1, representa o modelo SD, que consiste em um conjunto de nós e ligações. 
Os nós representam os atores e cada ligação entre os atores, indica que um ator depende 
do outro ator para que os objetivos sejam alcançados. Chamamos o ator que depende de 
outro ator de Depender e o ator que ajuda o outro ator de Dependee e o objeto em torno do 
qual o centro de relacionamento de dependência como Dependum. A Figura 2.1, representa 


um serviço de compra por meio de um e-commerce. Como podemos observar na Figura 
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2.1, existem três atores, “Customer as buyer [service]”, “Middleman as Seller [Service] 
e “Supplier [Service]”. O ator “Customer as buyer [service]” depende do ator “Middleman 
as Seller [Service]” para conseguir um preço baixo junto ao fornecedor, ou seja, existe a 
intenção do ator em realizar esse objetivo e por isso é utilizado a ligação Dependência de 
Objetivo e para o ator “Middleman as Seller [Service]” conseguir alcançar esse objetivo o 
mesmo depende do ator “Customer as buyer [service]” para obter informações de valores 
e automaticamente o pagamento para cumprir com o serviço. Por isso é utilizado a ligação 
Dependência de Tarefa. Mas para o ator “Middleman as Seller [Service]” cumprir com seus 
objetivos ele ainda depende do ator “supplier [Service]”, para fazer um acordo sobre o 
preço, além de atrair mais clientes. Esse último utiliza a ligação Dependência de Softgoal, 
por motivo de não ter um critério bem definido de como vai atrair mais clientes. A mesma 
coisa acontece para a ligação de Dependência de Softgoal de “Good Quality [Service]” e 
“Acceptable price [service]”. 


Low Price 
Service Provide 
Be Found 


ame a Pricê 
[Service] 


Attract More 
Customers 
[Service] 


Middleman 


eller 
ae | emvice] Supplier 
(Service) [Service] 


Agreement 
on Price [P] 


Acceptable 
Price 
[Service] 


Figura 2.1 — Representação do modelo SD. Fonte (Wiki 1*) 


Na próxima seção, serão discutidos os elementos que compõem o Modelo 
Estratégico Logico, entretanto, os significados dos elementos geralmente são os mesmos 
que foram descritos na Tabela 2.1, com exceção da satisfação dos elementos que acontece 
internamente. 
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2.1.2 Modelo Estratégico Lógico (SR) 


Modelo Estratégico Lógico (SR), é usado para descrever os relacionamentos 
internos de um determinado Ator, como: (i) interesses; (ii) preocupações; e (iii) motivações 
dos atores participantes de um processo. Portanto, o SR se difere do SD na forma de 
tratamento na definição do processo, na investigação mais detalhada nas razões existentes 
e na intencionalidade por trás das dependências entre os Atores. Ou seja, um representa 
os relacionamentos externos, enquanto o outro representa os relacionamentos internos. De 
acordo com Yu (1995), o modelo descreve problemas e as preocupações que os agentes 
têm sobre os processos existentes e as alternativas propostas, e a forma que eles podem ser 
tratados em termos de uma rede de relações meio-fim. SR é um gráfico que contém vários 
tipos de nós e ligações que juntos fornecem uma estrutura de representação que expressam 
as razões por trás das dependências (Wiki /). Entende-se nós os objetivo, tarefa, recurso 
e softgoal, e por ligações, são as ligações meio-fim, ligações de contribuição e as ligações 
de decomposição, descrito na Tabela 2.2. Conforme Yu (2001), o SR fornece um nível 
mais detalhado de modelagem através de uma visão de dentro dos atores para modelar 
estruturas intencionais e relacionamentos internos. O modelo SR fornece uma descrição 
intencional de processos em termos de elementos de processo e as razões por trás deles. 
Enquanto o modelo SD mantém um nível de abstração apenas para as relações externas 
entre atores. Os modelos SR renuncia a este nível de abstração, aprofundando mais sobre 
os processos internos dos Atores (Yu, 1995). O modelo SR é usado na Engenharia de 
Requisitos, com o propósito de identificar os atores em um determinado setor da empresa 
ou organização, além de modelar a estrutura interna e seus relacionamentos e identifica a 
forma como os atores alcançam os seus objetivos. 

Da mesma forma que acontece no SD, o SR também possui as suas ligações de 
dependências: (i) Dependência de Objetivo; (ii) Dependência de Tarefa; e (iii) Dependência 
Softgoal. Além das ligações meio-fim, decomposição e contribuição que é decomposto em: 
(i) make; (ii) break; (iii) unknow; (iv) some+; (v) some»; (vi) and; (vii) help, (viii) hut; e (ix) or. 
A Tabela 2.2 representa a sintaxe e os conceitos dos elementos que compõem o modelo 
SR. 
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Tabela 2.2 — Sintaxe e conceitos dos elementos pertencentes ao modelo SR 


Sintaxe 


Definição 


Objetivo 


Representa o desejo intencional de um ator (Wiki 
1). Por exemplo, desejo concluir a disciplina de 
ontologia. E um desejo intencional a ser alcançado 
por um ator. Para Yu (1995), um Objetivo é uma 
condição ou estado de coisa no mundo que o Ator 
gostaria de alcançar. 


Softgoal 


É um objetivo, mas seus critérios de satisfação não 
são claros e definidos (Wiki |). Um softgoal é um 
objetivo cujos critérios para a satisfação não são 
bem definidos a priori, e está sujeito a um modo de 
satisfação de raciocínio pelas partes interessadas. 
Por exemplo, tornar um servidor de aplicação 
seguro. Pois não fica claro de que forma esse 
objetivo será alcançado. 


É uma tarefa específica, realizada de uma maneira 
particular (Wiki *”). Por exemplo, aplicar as regras 
nos servidores para torna-se seguro. Ou seja, 
realizar ações para que a tarefa seja executada. 


Recurso 


É quando um ator deseja a prestação de alguma 
entidade física ou intencional (Wiki |). Por exemplo, 
é necessário ter o valor de uma mensalidade para 
fazer o pagamento. Neste caso, assume-se que não 
há questões em aberto ou pergunta a respeito de 
como a entidade será alcançado. 


Belief 


É uma condição sobre o mundo que o ator acredita 
ser verdade (Wiki /). Ou seja, a crença é diferente 
de objetivo, já que, neste caso, o ator não tem 
intenção ou desejo explícito de fazer a condição 
específica se tornar verdadeira. Por exemplo, uma 
pessoa acredita que Vitória é a capital do estado do 
Espírito Santo. 


Objetivo 


Aponta uma relação entre um fim e um meio para 
alcançar um objetivo. Ou seja, um Meio pode ser 
representado por uma Tarefa e o Fim pode ser 
representado por um Objetivo, no qual a seta aponta 
do meio para o fim. Portanto, a Tarefa é executada 
para alcançar um Objetivo (Wiki |). Por exemplo, a 
tarefa de realizar um concurso público (meio), com o 
objetivo de garantir um emprego estável (fim). 
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Recurso 


ED) ( ste ) 


As ligações de decomposição tem como 
representação uma tarefa está ligada a seus nós 
por ligações de decomposição. Ou seja, uma tarefa 
pode ser decomposta por quatro tipos de elementos, 
são eles:(i) subgoal; (ii) uma subtarefa; (iii) um 
recurso; por fim um (iv) softgoal. 


ms LR 
q, epi ici 


As ligações de contribuições se dividem em nove 
categorias, são elas: Make, Some, Help, Unknown, 
Break, Some-, Hurt, Or, And. O link Make tem uma 
contribuição forte para satisfazer um softgoal, já a 
ligação Help tem a contribuição positiva, mas não 

o suficiente para satisfazer o softgoal. Entretanto, 

a ligação break, é uma contribuição negativa para 
recusar a satisfação de um Softgoal. A ligação Hurt, 
é uma contribuição negativa, porém ela sozinha não 
é capaz de recusar ou negar a satisfação de um 
softgoal. Já a ligação Some+, é uma contribuição 
positiva, mas cuja força para contribuir com o 
softgoal é desconhecida. Ao contrário da ligação 
Some-, tem uma força de contribuição negativa, mas 
cuja força de sua influência é desconhecida. Por fim, 
a ligação Or, é uma contribuição cuja satisfação é 
obtida se alguns dos elementos forem satisfeito. 


A Figura 2.2, apresenta as intencionalidades do ator “Gerente de Equipe”. De acordo 


com (Wiki i*), os limites indicam as intenções de um determinado ator, e todos os elementos 


dentro do limite, estão explicitamente desejados pelo ator. Portanto, para atingir o objetivo 


muitas vezes os atores dependem das intenções dos outros atores, por meio de ligações 


de dependência entre as fronteiras dos atores. Para Yu (2001), os elementos intencionais 


aparecem no modelo SR não somente como dependências externas, mas também com 


elementos internos ligados por relações de ligação meio-fim e ligação de decomposição. 
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Figura 2.2 — Representação do modelo SR. Fonte (Wiki i*) 


A Figura 2.2, representa um modelo SR, neste modelo o ator “Gerente Equipe” tem 
como objetivo interno de marcar uma reunião. Para ele alcançar esse objetivo, o mesmo foi 
decomposto em vários subobjetivos e crenças. O objetivo “Marcar reunião”, foi decomposto 
em “Coletar Horário disponível” e “Escolher Horário”. Como podemos observar na Figura 
2.2, essas duas decomposições foram ligadas através da ligação de decomposição AND. 
Ou seja, para marcar a reunião os dois objetivos têm que ser satisfeitos, “coletar horário 
disponível” e “escolher um horário”. Já o subobjetivo “coletar horário disponível” também 
foi decomposto em outros dois subobjetivos, são eles, “Coletar pessoalmente” e “Coletar 
por sistema”. Neste caso, os dois subobjetivos estão ligados por meio das ligações de 
decomposição OR. Ou seja, para “coletar horário disponível”, basta satisfazer apenas um 
subobjetivo. Portanto, tanto faz alcançar o subobjetivo “Coletar pessoalmente” como o 
subobjetivo “Coletar por sistema”. Sendo que este último contribui positivamente para a 
crença “Minimizar esforço”, já o segundo contribui negativamente para “Minimizar esforço”. 
O subobjetivo “Escolher horário” é decomposto em “Escolher manualmente” e “Escolher 
automaticamente”, e esses dois subobjetivos estão ligados ao subobjetivo “Escolher 
horário” por meio da ligação de decomposição OR, portanto, tanto faz satisfazer um dos 
subobjetivos para alcançar o objetivo. O segundo subobjetivo contribui de forma positiva 
para minimizar o “conflito de horário”, mas contribui negativamente para “maximizar o grau de 
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participação” por partes dos funcionários. Portanto, o subobjetivo “Escolher manualmente” 
contribui positivamente para “maximizar o grau de participação” dos funcionários, mas, por 
outro lado, contribui negativamente para “minimizar o conflito” de horário. E tanto as duas 
crenças são decomposto da crença “Quality Of Schedule”, que são ligados por meio da 
ligação de decomposição AND. 


2.2 —- ONTOLOGIA 


O termo “Ontologia” vem se destacando nos últimos anos na área de Ciência 
da Computação, mais especificamente na área da Inteligência Artificial (IA), com uma 
interpretação um pouco diferente voltada para a modelagem de conhecimento. O primeiro 
trabalho que envolveu ontologia na área da Ciência da Computação, foi um trabalho sobre 
“Fundamentos de Modelagem de dados” em 1967, por S.H. Mealy (Guizzardi, 2007). Mas o 
termo “Ontologia” teve um crescimento notável nos anos 90, com a necessidade da criação 
de representação de princípio de conhecimento de domínio. 

Mas o que vem a ser Ontologia? De acordo com o dicionário Aurélio?, no sentido 
filosófico, Ontologia é a ciência do ser em geral. Parte da metafísica que estuda o ser 
em geral e suas propriedades transcendentais. No sentido epistemológico, (ant) vem do 
particípio presente do verbo grego (enai) que significa “Ser” e (logia) em latim, que significa 
estudo. 

Guarino (1998) defende a definição de ontologia, como um vocabulário específico 
usado para descrever uma certa realidade e um conjunto de decisões explícitas, de forma 
a fixar de maneira rigorosa do significado pretendido para o vocabulário. Capturando os 
conceitos e relações em domínio e conjunto de axiomas, que venha a restringir a sua 
interpretação. Ainda segundo o autor, uma ontologia é considerada um conjunto de 
axiomas lógicos concebidos para explicar o significado pretendido de um vocabulário. Em 
outras palavras, tendo uma linguagem L com um compromisso ontológico K, uma ontologia 
para L é um conjunto de axiomas concebidos de uma forma, que o conjunto de modelos 
se aproximam da melhor forma possível do modelo destinado a L, como pode ser visto na 
Figura 2.8. 


2. http:/Aww dicionariodoaurelio.com/ 
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Conceituação C 


Compromisso K = <C,B> 


Linguagem L 


E 


Modelo M(L) 


Modelos destinados I (L) 


Figura 2.3 — Modelos destinados de uma linguagem lógica reflete seu compromisso com a 
conceituação. Fonte (Gurarino, 1998). 


Muitas vezes o termo ontologia é entendido de forma incorreta, pois o termo 
Ontologia (com a letra “O” em maiúsculo) tem o significado voltado mais para a área de IA, 
ou seja, refere-se a um artefato de engenharia, constituído por um vocabulário específico 
usado para descrever certa realidade (Guarino, 1998). Já o termo ontologia (com a letra “o” 
em minúsculo), significa um sistema particular de categorias que representa certa visão do 
mundo. Ou seja, é um sistema independente de um idioma. 

A classificação das ontologias, é dada por uma visão ótica de cada autor. Por 
exemplo, de acordo com (Uschold; Gruninger, 1996) a ontologia é vista por duas dimensões, 
são elas: (i) o grau de formalidade, que depende de como a ontologia é descrita. Podendo 
ser classificada em, altamente informal, rigorosamente formal, semiformal e semi-informal. 
Portanto, uma ontologia pode ser desenvolvida para interoperabilidade, comunicação, 
etc; (ii) natureza do assunto, ou seja, natureza do assunto que a ontologia está tratando. 
Podendo ser classificada em: ontologia de domínio, ontologia de tarefas, métodos, 
resolução de problemas e ontologia de representação. 

Para (Van Heijst; Schreiber; Wielinga, 1997), a ontologia também é vista por duas 
dimensões: (i) estrutura de conceituação, representada por ontologia terminológica, 
ontologia de informação e a ontologia de modelagem de conhecimento; (ii) natureza da 
conceituação, representada pelas ontologias de representação de conhecimento, ontologia 
de domínio, ontologias genéricas e por último, ontologia de aplicação. 

Para (Guarino, 1997), a ontologia também é vista por duas dimensões: (i) nível 
de detalhes, representada por ontologia de documentação e ontologia divisível; (ii) nível 
de dependência e da natureza da conceituação, representada pela ontologia genérica, 
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ontologia de representação, ontologia de domínio e ontologia de aplicação. Para mais 
detalhes pode ser visto em (Van Heijst; Schreiber; Wielinga, 1997) , (Uschold; Gruninger, 
1996) e (Guarino, 1997). 

(Guarino,1998) define quatro tipos de ontologias de acordo com a sua generalidade: 
(i) Ontologia de nível superior (ou ontologia fundamental) — descrevem conceitos gerais, 
como espaço, tempo, objeto, evento, ação, entre outros. Em outras palavras, conceitos 
independentes de um problema ou domínio particular; (ii) ontologia de domínio — descrevem 
vocabulários relacionados a um domínio genérico, por exemplo, ecossistema e educação. 
Especializando os termos introduzidos na ontologia de nível superior; (iii) ontologia de 
tarefa — descrevem vocabulários relacionados a uma tarefa genérica, por exemplo, vendas 
e lecionar. Especializando os termos introduzidos na ontologia de nível superior; por último, 
(iv) ontologia de aplicação — descrevem conceitos dependendo de um determinado domínio 
e uma tarefa em particular. Especializando os termos introduzidos tanto em ontologia de 
domínio e ontologia de tarefa. Em outras palavras, esses conceitos correspondem a papeis 
desempenhados por entidade de um determinado domínio, enquanto ocorre uma atividade. 


Conforme representado na Figura 2.4. 


Ontologia de nível superior 
Ontologia de domínio Ontologia de tarefa 


Ontologia de aplicação 


Figura 2.4 — Tipos de ontologias. Fonte (Guarino, 1998) 


As ontologias podem ser utilizadas para diversos propósitos, como: engenharia do 
conhecimento, representação do conhecimento, modelagem de informação, integração de 
informação, análise orientada a objetos, recuperação de informação e extração, gestão do 
conhecimento e da organização, análise ontológica de linguagens, etc. 

O uso de ontologias, apresenta inúmeras vantagens: (i) Comunicação e colaboração 
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entre pessoas. Reduzindo conflitos conceituais e terminológicos dentro das organizações; 
(ii) Formalização. Eliminando as contradições e inconsistências; (iii) Interoperabilidade 
entre sistemas. Utilizada nas traduções em diferentes bases de dados, fornecendo uma 
conceituação única; (iv) representação do conhecimento e reuso. Cria-se um vocabulário 
de consenso, representando de forma explícita o conhecimento em seu maior nível de 
abstração (Guizzardi, 2007). 

Alguns exemplos do uso de ontologias são apresentados a seguir: (i) O trabalho 
de (Azevedo et al, 2011), tem como objetivo propor a inclusão de conceitos como 
preocupações, avaliações, objetivos, princípios e normas para ArchiMate. Foi utilizada 
uma ontologia bem fundamentada denominada UFO para interpretar conceitos, e como 
resultado, propor recomendações bem fundamentadas para melhoria da extensão. (ii) 
(Guizzardi; Falbo; Guizzardi, 2008), apresenta as evoluções feitas em uma ontologia de 
fundamentação particular denominada UFO. Além disso, discutir a relevância de ontologias 
de fundamentação no desenvolvimento de ontologias de domínio por meio de um estudo 
de caso no domínio de processos de software; (iii) (Azevedo et al, 2013), apresenta uma 
análise ontológica dos conceitos introduzidos, focando em particular os conceitos de 
recursos, capacidade e competência. Como resultado, foi proposto recomendações bem 
fundamentadas de melhorias, aumentando suas possibilidades de adequação e integração; 
(iv) (Carvalho et al, 2013), propôs um alinhamento semântico entre duas abordagens 
orientadas para objetivos complementares: a extensão ArchiMate e o Goal-Question-Metric. 
Sendo que as abordagens são semanticamente analisadas por uma ontologia denominada 
UFO, que fornece a semântica do mundo real para ambas as línguas, servindo como uma 
ontologia de referência para apoiar a análise ontológica de conceitos e relações de ambas 
as abordagens e o alinhamento entre elas. 

As ontologias de fundamentação são ontologia de categorias bem fundamentadas 
filosoficamente e independente de domínio, que são utilizadas para melhorar as qualidades 
das linguagens de modelagens e modelos conceituais (Guizzardi; Falbo; Guizzardi, 2008). 
As ontologias de fundamentação é utilizada para desenvolver as diretrizes ontológicas para 
tentar auxiliar no entendimento universal dos conceitos dos construtores de linguagem i*, 
que são interpretados de várias formas por diversos pesquisadores. Em particular esta 
dissertação vai concentrar na Ontologia de Fundamentação Unificada (UFO) proposta por 
Guizzardi (2005). UFO tem sido desenvolvida baseada em um número de teorias das áreas 
de Ontologias Formais, Lógica Filosófica, Filosofia da Linguagem, Linguística e Psicologia 
Cognitiva (Guizardi; Falbo; Guizzardi, 2008). 


2.2.1 Ontologia de Fundamentação Unificada — UFO 


A Ontologia de Fundamentação Unificada, denominada UFO, foi desenvolvida com 
base em números de teorias das áreas de Ontologias Formais, Lógica Filosófica, Filosofia 
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da Linguagem, Linguística e Psicologia Cognitiva (Guizzardi, 2005). Foi desenvolvida 
pensando em unificar ontologias como, GFOº e a DOLCE*, aproveitando suas características 
positivas e eliminando as limitações detectadas, como, a dificuldade de capturar conceitos 
básicos de linguagem de modelagem conceitual. 

A UFO tem sido aplicada com sucesso para avaliar, projetar e reprojetar, além de 
integrar os modelos de linguagens de modelagem conceitual, provendo a semântica do 
mundo real para seus elementos de modelo (Guizzardi, Falbo; Guizzardi, 2008). 

A UFO é dividida em três partes complementares: (i) UFO-A, é uma ontologia de 
indivíduos duradouros (endurants) é o core da UFO; (ii) a UFO-B, é uma ontologia de 
eventos (perdurants); por último, a UFO-C, é uma ontologia que trata especificamente sobre 
conceitos sociais, mais especializados de UFO-A e UFO-B. Esta dissertação irá abordar 
conceitos específicos de UFO-C, ontologia esta, que será detalhada, por ser considerada 
parte fundamental para o desenvolvimento dessa dissertação. 


UFO-C 


Nesta seção iremos apresentar uma ontologia de fundamentação que trabalha 
com conceitos sociais e intencionais, como, agentes, estados intencionais, objetivo, ação, 
normas, compromissos sociais/reclamações, relações de dependência sociais, denominada 
UFO-C. A UFO-C é mais especializada da UFO-A (objeto físico e momento individual) e da 
UFO-B (Evento). Em UFO-C um agente é definido como um endurant concreto, ou seja, 
uma entidade que perdura no tempo, mantendo a sua identidade, que pode suportar certos 
estados intencionais (Guizzardi; Guizzardi, 2010). 

O Objeto físico é mais especializado em agente físico e objeto não-agentivo. Sendo 
que o primeiro é um agente físico que cria eventos de ações o qual se atribui em um estado 
mental (Por exemplo, um homem, um cachorro). Já o segundo é um objeto físico que não 
é um agente físico (Por exemplo, um livro, um recurso, uma árvore). No caso de um objeto 
não-agentivo ser um recurso, significa que o objeto é utilizado por um agente físico com 
fins específicos e, normalmente controlado por este ou outro agente físico (Guizzardi, 2007) 
(Exemplo, um homem utilizando uma impressora). 

O agente físico, é mais especializado em agente institucional, agente humano e 
agente artificial. A diferença entre agente institucional para agente humano, é que o agente 
institucional possui vários agentes humanos (Exemplo, Pessoas) e agente institucional pode 
ser considerado departamentos ou divisões. (Exemplo, A UFES possui o departamento de 
Ciência da computação que nele são alocados vários professores). E o agente artificial se 
diferencia dos demais, por ser considerado um software ou hardware. 

3. GFO é uma ontologia de alto nível utilizada em aplicações de Biomedicina, além de ser usada como fundamento 
ontológico para modelagem conceitual(Almeida et al., 2010, Herre 2006) . 


4. DOLCE é uma ontologia que tem como objetivo descrever categorias ontológicas subjacentes à linguagem natural e 
ao senso comum humano (Almeida et al., 2010, Masolo 2003) . 
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Evento de ação e evento não-ação são dois tipos de conceitos vindos de UFO-B, ou 
seja, Evento de UFO-B é mais especializado em evento de ação e evento não-ação. Sendo 
que o primeiro é um evento criado por uma ação vinda de um agente físico (Por exemplo, 
Escrever uma carta, Revisar uma dissertação). Já o segundo, é um evento que não é criado 
por uma ação vinda de um agente físico, é um evento que é criado pelo próprio ambiente, 
mas pode ser observado pelo agente físico (Guizzardi, 2007) (Exemplo, um amanhecer, 
prazo da escrita de uma dissertação). 

Evento de ação é mais especializado em ação de evento complexo, evento de 
ação atômica e evento de ação de execução de plano, são eventos intencionais, que tem 
como objetivo satisfazer o conteúdo proporcional de alguma intenção (Martins, 2009). O 
conceito de evento de ação complexa é um evento composto de dois ou mais eventos 
(Exemplo, uma crise asmática). O conceito de evento de ação atômica é um evento de 
ação que acontece instantaneamente (Exemplo, Pegar um livro em uma estante, enviar 
uma mensagem). Sendo que o segundo exemplo, também é visto como um evento de ação 
comunicativa, em outras palavras, um agente físico, envia ou recebe eventos de um evento 
de ação comunicativa com propósito de informar um agente físico de possíveis mudanças 
em sua linha de ação ou no ambiente, podendo alterar a crença do agente físico (Guizzardi, 
2007). Ainda de acordo com o autor, uma Execução de plano pode ser definido como uma 
intenção de executar uma ou mais ações, portanto, a execução de um plano tem com 
objetivo obter um resultado particular do agente físico. Para isso, a execução do plano está 
ligada diretamente ao tipo de plano, que é considerado uma descrição geral de sequência 
de ações que um agente físico executa. 

O conceito de momento intrínseco de UFO-A é mais especializado em momento 
social e momentos mentais. Sendo que um momento intrínseco é existencialmente 
dependente de um agente particular, ou seja, é uma parte inseparável de seu estado mental 
(Exemplo, Um desejo ou uma intenção), intenção em UFO é entendida em um sentido mais 
amplo, do que a noção de intenção de alguma coisa, ou seja, refere-se à capacidade de 
algumas propriedades de certos indivíduos para referir às possíveis situações da realidade 
(Bringuente; Falbo; Guizzardi, 2011). Em outras palavras, um momento intrínseco é inerente 
(possui uma relação) a um agente físico individual. 

Um momento mental é mais especializado em desejo, intenção, crença. Onde a 
crença é a informação que o agente físico individual tem sobre o ambiente ou outro agente 
físico individual (Por exemplo, minha crença de que Vitória é a capital do Espírito Santo). 
Já o desejo e a intenção referem-se ao objetivo de um agente. Um desejo expressa a 
vontade de um agente físico individual em direção em um determinado estado de coisa, 
ou seja, o objetivo é um estado de coisas a serem desejados (Exemplo, eu desejo que o 
Atlético Mineiro seja campeão Mundial). E mais do que um desejo, uma intenção é um 
compromisso interno de um agente físico individual para agir em direção a essa vontade 


(Guizzardi,2010)(Exemplo, minha intenção é morar em Foz do Iguaçu daqui a dois anos). 
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Um objetivo é especializado em Hardgoal e softgoal. Em Tropos, a definição de 
Hardgoal está associada a uma condição específica para verificar se o objetivo foi satisfeito 
ou não. Ao contrário, o softgoal, não tem essa condição clara (Exemplo, o objetivo é a 
conclusão do mestrado. Para alcançar o objetivo, entretanto, possui critérios bem definidos 
para a conclusão do mestrado como, concluir os créditos, escrever e publicar um artigo, 
escrever a dissertação e defender. Essas são condições específicas para satisfazer o 
objetivo final que é a conclusão do Mestrado). Em outras palavras, o conteúdo proposicional 
de uma intenção é um objetivo. Ou seja, uma situação na realidade pode satisfazer a 
proposição que representa o conteúdo proposicional de um momento intencional (Martins, 
2009). A Figura 2.5 representa parte da ontologia UFO-C. 


Entidade Concreta 
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Figura 2.5 — Parte da ontologia UFO-C 


2.3 - ESTUDOS EMPÍRICOS 


O estudo empírico hoje é uma das formas mais eficientes de demonstrar a eficiência 
de uma nova abordagem ou pesquisa realizada. As pesquisas nas áreas de engenharia de 
software têm poucos estudos empíricos em relação à área médica. Muitas vezes estudos 
em engenharia de software empírica são às vezes exploratória e muitas vezes envolvem 
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desenvolvedores de software e organizações de desenvolvimento (Kampenes; Anda; 
Dybaa, 2008). Portanto, muitos artigos ou trabalhos realizados na área da computação 
têm poucas avaliações empíricas e a proporção de experimentos é particularmente baixo 
em relação à área humana. Para Vokac (2002), a ciência ideal, seria ter um conjunto de 
observações empíricas para cada teoria, seja ela para reforçar a sua teoria ou enfraquecê- 
la. 

Experimentação é o núcleo do processo científico, e é através dos experimentos 
que se verificam as teorias, exploram os fatores críticos e dá luz ao fenômeno novo 
para que as teorias possam ser formadas e corrigidas (Travassos, 2002). Ainda para o 
autor, novos métodos, técnicas, linguagens e ferramentas não deveriam somente serem 
publicados ou colocados à venda, sem qualquer tipo de experimentação e validação. Além 
do mais, é necessário avaliar novas invenções, teorias e sugestões em comparação com 
as existentes (Travassos, 2002). 

Existem quatro tipos de métodos para condução de experimentos na área da 
computação: (i) Método científico, esse método observa o mundo, sugere modelo ou teoria 
de comportamento, mede e analisa, verifica as hipóteses do modelo ou da teoria. Esse 
método é utilizado com o propósito de entender algo (Exemplo, um ambiente ou produto); (ii) 
Método de engenharia, esse método observa as soluções existentes, sugere, desenvolve, 
mede e analisa soluções mais adequadas (Exemplo, a melhoria de um processo); (iii) 
Método experimental, esse método sugere o modelo, desenvolve o método qualitativo e 
ou quantitativo (ver definições na Tabela 3), aplica um experimento, além de medir, avaliar 
e repetir todo o processo; (iv) por último, o método analítico, esse método além de sugerir 
uma teoria formal, ele também desenvolve novas teorias, deriva os resultados e quando é 
possível compara com as observações empíricas (Travassos, 2002). 

Nessa dissertação iremos adotar o método experimental, com o objetivo de aplicar 
o método quantitativo para validar as hipóteses, medir o tempo de desenvolvimento de 
modelos utilizando as diretrizes ontológicas. Além de ter a possibilidade de repetir todo o 
processo caso seja necessário. 

Existem vários objetivos para aplicar um experimento, dentre eles estão: a 
caracterização, avaliação, previsão, controle, e melhoria de produtos, processos, recursos, 
modelos e teoria. Com a execução de experimentos, nos permite responder tais perguntas: 
O que está acontecendo? Posso estimar algum futuro? Posso manipular o evento? Posso 
melhorar o evento? (Travassos, 2002). Essa nova diretriz é melhor que as diretrizes já 
utilizadas? Em outras palavras, com a aplicação do experimento, temos a capacidade de 
compreender melhor a natureza dos processos das informações. Além de ajudar a formar 
uma base sólida de conhecimento reduzindo drasticamente as incertezas sobre quais 
teorias, e metodologias são adequadas. 

Tabela 2.3, apresentamos os principais conceitos, que nos permitem 


fazer um planejamento de um experimento. Para mais detalhes consulta em 
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(Travasso,2002),(Kochanski, 2009),( Kampenes; Anda; Dybaa, 2008) e (Juristo; Moreno, 


2001). 


Tabela 2.3 — Principais conceitos para planejar um experimento. 


Descrição Conceito 
Estratégia de pesquisa | Quantitativa Tem como propósito obter uma relação numérica 
entre variáveis ou alternativas sobre pesquisa. 
Geralmente é conduzido através de um experimento 
controlado (Travassos, 2002). 
Qualitativa São vistos como mais flexíveis. 
Tipos de avaliações Surveys É de natureza retrospectiva e geralmente é realizada 


empíricas 


em grande conjunto de informações (Luders, 2003). 
E tem como objetivos: (i) ser descritivo; (ii) ser 
explanatório; e (iii) ser exploratório. 


Estudo de caso 


É utilizado para monitorar os projetos, atividades e 
atribuições. Portanto, visam observar um atributo 
específico e estabelecer o relacionamento entre 
atributos diferentes (Travassos, 2002). 


Experimento 


Experimentos são usados para investigar relações 
causais em ambientes controlados. Além do 

mais, experimentos são replicáveis por definição 
(Luders,2003). 


Tipos de Estudos 


Experimental 


É quando se usa distribuição aleatória dos 
componentes envolvidos. Para Sjoberg (2005), 
experimental é um estudo em que uma intervenção 
é deliberadamente introduzida para, observar seus 
efeitos. 


Quase-experimental 


É quando a distribuição dos participantes não é 
aleatória e se utiliza múltiplos grupos. 


Não-experimental 


É quando a distribuição não é aleatória e nem 

se utiliza múltiplos grupos. A categoria não 
experimental é um experimento em que as unidades 
não são atribuídas a condições aleatoriamente 
(Sjober, 2005). 


Realização do 
Experimento 


in-vitro 


É considerado um experimento artificial, executado 
em um ambiente controlado. 


in-vivo 


É considerado um experimento observacional, no 
qual os sujeitos pesquisados estão em um ambiente 
convencional. 


in-virtuo 


O experimento é realizado tanto no ambiente 
controlado, como no ambiente convencional através 
de uso de modelos computacionais. 


in-silício 


O experimento realizado em um ambiente 
controlado, os participantes utilizam modelos 
computacionais. 


Estratégia de seleção 
de grupo 


Controle 


É formado pela metade dos participantes. No 

qual, nenhum deles tem contato com o método de 
estudo. O grupo de controle é aquele que servirá de 
base para comparação com o grupo experimental 
(kochanski,2009) 


Experimental 


É formado pela metade dos participantes. No qual, 
eles terão contato com o método de estudo. 
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Hipótese 


Abstrata 


Refere a sentenças de alto nível em linguagem 
natural que são normalmente declaradas em termos 
do dia a dia. 


Concretas 


São declaradas em termo de design de estudos 
(kochanski, 2009). Sempre que for definir uma 
hipótese, é necessário que tenha uma hipótese 
nula (HO), ou seja, é a negação da hipótese que se 
pretende obter os resultados. Portanto, a hipótese 
que se deseja chegar ao resultado (H1), deve ser 
formulada na forma afirmativa, ao contrário da 
hipótese nula. O principal objetivo do experimento é 
rejeitar a hipótese nula a favor de outras hipóteses 
(Travassos,2002). 


Tipo de escala 


Nominal 


Representa a atribuição mais ampla de numerais. 
Os numerais são usados apenas como rótulo ou 
números de tipos. Por exemplo, número da camisa 
de jogador de futebol, é utilizado para identificar a 
pessoa (Stevens, 1947). 


Ordinal 


Surge da operação de rank-ordenação, uma vez que 
qualquer transformação de preservação da ordem 
vai deixar a forma de escala invariante. (Exemplo 
escala de dureza de minerais). 


Intervalar 


É uma forma quantitativa no sentido comum da 
palavra e quase todas as medidas estatísticas 
usuais são aplicadas aqui. 


Proporcional 


Dispõe-se de um zero absoluto, sendo uma escala 
mais completa e sofisticada das escalas. E uma 
quantificação produzida a partir do zero que é fixo 
na medida. 


Absoluta 


São as mais comuns encontradas em física e só 
são possíveis quando existem operações para 
determinar as quatro relações, são elas: igualdade, 
rank-order*, igualdade de intervalos e igualdade de 
proporções. 


Tipos de variáveis 


Dependentes 


Representam as saídas dos processos do 
experimento. Representa os efeitos causados pelos 
fatores do experimento. As variáveis dependentes 
são variáveis que não conseguem medir 
diretamente. Por exemplo, a qualidade. (Vockac, 
2002). 


Independentes 


Representam as entradas dos processos do 
experimento. 


Fase de operação 


Preparação 


Considerada uma etapa importante para a 
realização do experimento. Antes de acontecer 

o experimento, é necessário realizar diversas 
preparações. Quanto melhor for a preparação, mais 
fácil será a aplicação do experimento. De acordo 
com Wohlin (2000), dois aspectos são importantes, 
o primeiro é a coleta das informações sobre os 
participantes e a segunda é a preparação dos 
materiais que serão utilizados no experimento. 


Execução 


O pesquisador deve fazer com que as atividades 
sejam realizadas em um menor espaço de tempo 
possível. E nessa fase que ocorre as coletas dos 
dados do experimento, que pode ser feita de forma 
manual ou automática. 


5. Rank-order é um arranjo de acordo com a classificação. 
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Validação dos Acontece logo no início da coleta dos dados. É 
dados importante verificar a veracidade dos dados e se 

os mesmos foram coletados corretamente. Além de 
verificar se o experimento foi realizado da forma que 


foi planejado. 
Fase de análise e Estatística Trata da apresentação dos resultados e 
interpretação descritiva processamento dos dados. E utilizada para 


descrever e apresentar graficamente aspectos de 
interesses representados em um conjunto de dados 
(kochanski, 2009). 


Redução do Tem como objetivo eliminar pontos de dispersãos, 
conjunto de dados | | tanto com base nos dados calculados a partir da 
realização do experimento, quanto dos dados 
coletados durante o experimento (Kochanski, 2009). 


Teste da hipótese Tem como finalidade verificar se é possível rejeitar 
a hipótese nula, baseado na amostra de uma 
distribuição estatística. Existem duas formas de 
fazer o teste da hipótese, são elas: Paramétricos e 
não Paramétricos. Usa o teste paramétrico, quando 
se tem um modelo que envolve uma distribuição 
específica. Caso os parâmetros não forem medidos 
dentro de um intervalo de escala, utiliza-se o teste 
não-paramétrico (Kochanski, 2009). 


O processo de experimento contém as seguintes atividades (Kochanski, 2009): 


Definição: é nesse momento que temos que ter em mente, que o experimento 
é uma parte importante do processo de aprendizagem. Portanto, é nesse mo- 
mento que são formuladas as hipóteses, as quais são investigadas pelo experi- 
mento. E dependendo do seu resultado podemos definir novas hipóteses para 
a investigação. 


Planejamento: o planejamento do experimento recebe como entrada os itens 
produzidos na fase de definição. Nesta etapa, são realizadas: (i) seleção de 
contexto; (ii) formulação de hipótese; (iii) seleção de variáveis; (iv) seleção de 
participantes; (v) design de experimento; (vi) instrumentalização; por fim, (vii) 
avaliação de validade. 


Operação: esta fase é considerada a fase crucial para o sucesso do experi- 
mento. Pois é nessa fase que devemos motivar os participantes a realizarem as 
atividades de forma séria, caso contrário, os resultados serão inadequados. É 
nessa fase que a coleta de dados é importante, pois servirão como base para 
as análises posteriores. Também é muito importante nessa fase a realização 
cuidadosa do monitoramento do processo, como, garantir que tudo está sendo 
feito de acordo com o planejamento. Anotar tudo que acontecer no momento 
da aplicação do experimento, como, participantes que desistir de realizar o ex- 
perimento e falta de resposta em levantamentos. A fase de operação do experi- 
mento é composta pelas seguintes atividades: (i) preparação; (ii) execução; por 
último, (iii) validação dos dados. 


6. Ponto de dispersão, são erros em um conjunto de dados que pode acontecer de forma de erro sistemático. Ou seja, 
acontece quando o ponto de dados é maior ou menor dos demais pontos. 
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* Análise e Interpretação: o processo de análise e interpretação é composto 
pelas seguintes atividades: (i) Estatística descritiva; (ii) redução dos dados; (iii) 
teste da hipótese. Essa fase depende muito da fase de operação, pois é através 
da coleta de dados e a sua interpretação que obtemos as conclusões. 


* Apresentação e conclusões: A partir da análise dos dados, devem ser obtidas 
as conclusões sobre os resultados. E a apresentação dos resultados deve ser 
de forma gráfica, pois são úteis para publicação de resultados. Também novas 
execuções podem ser realizadas para validar a conclusão do experimento. 


2.4 - CONSIDERAÇÕES FINAIS DO CAPÍTULO 


Este capítulo tratou sobre i*, linguagem utilizada para modelar a primeira fase de 
modelagem de um sistema. Também apresentou alguns conceitos sobre, ator, tarefa, 
objetivo, softgoal, recurso, crença, ligação de contribuição e decomposição (ver definições 
nas seções 2.1.2). Ainda sobre i*, foi apresentado o modelo SD e o modelo SR. O modelo 
SD é usado para expressar uma rede de relacionamentos intencionais, estratégias entre 
atores. E o modelo SR é usado para descrever os relacionamentos interno do ator. 

Também foram apresentados conceitos de ontologia, tanto para área da IA, como 
para área de modelagem de conhecimento. Foram apresentados vantagens no uso 
de ontologias, além de descrever alguns trabalhos que usam ontologias. Em relação a 
ontologias de fundamentação, destacou-se, a ontologia de fundamentação unificada 
denominada UFO, ontologia proposta por Guizzardi(2005). Ontologia que se divide em 
UFO-A, UFO-B e UFO-C. No qual, UFO-A, se refere a indivíduos duradouros (endurants) 
sendo o core da UFO. A UFO-B é uma ontologia de eventos (perdurants), por fim, UFO-C é 
uma ontologia que trata sobre conceitos sociais, mais especializados de UFO-A e UFO-B. 

Por fim, tratou sobre estudos empíricos, trazendo alguns conceitos relevantes para 
realização de um experimento. Foi apresentada a abordagem de pesquisa, estratégia de 
pesquisa, método de pesquisa e tipos de avaliações empíricas. Abordagem de pesquisa se 
divide em três tipos: primeira a analítica, segunda a descritiva e a terceira explicativa (ver 
definição na seção 2.3). A estratégia de pesquisa trata da estratégia da pesquisa quantitativa 
ou qualitativa, sendo que a quantitativa tem como propósito obter uma relação numérica, 
ao contrário da qualitativa que é vista como mais flexível. As avaliações empíricas podem 
ser divididas em três tipos, são elas: surveys, estudo de caso e experimento (ver definição 
na seção 2.83). 

Este capítulo apresentou informações importantes para fundamentar e apoiar essa 
dissertação. 


Referencial Teórico 


24 


CAPÍTULO 3 
DIRETRIZES ONTOLÓGICAS PARA A CRIAÇÃO DE MODELOS i* 


Este capítulo apresenta as diretrizes ontológicas para a criação de modelos i*. Essas 
diretrizes foram criadas com base em interpretações ontológicas para os conceitos 
relacionados aos elementos e links de i*, utilizando UFO-A, UFO-B e UFO-C. A seção 3.1 
caracteriza o problema que as diretrizes se propõem a resolver, oriundo da existência de 
múltiplos dialetos do framework i*. A seção 3.2 descreve o método de análise ontológica 
para a realização da interpretação dos principais conceitos i*; a seção 3.3 é apresentada as 
principais interpretações dos conceitos i*, derivando, assim, as diretrizes ontológicas. E por 
fim, a seção 3.4 traz as considerações finais do capítulo. 


3.1 - INTRODUÇÃO 


Como já mencionado, i* possui diversos dialetos e variantes. Como dialetos de 
i*, podemos citar Tropos (Bresciani et al., 2004), a versão do Wiki i” e Goal-oriented 
Requirements Language (GRL) (Amyot; Mussabacher, 2011). Tropos é uma metodologia 
de desenvolvimento de sistemas orientado a agentes, inspirada na análise de requisitos 
fundamentada em conceitos sociais e intencionais. Como linguagem de modelagem, Tropos 
adota i*, propondo algumas variações em relação à proposta original da linguagem. O Wiki 
i* é um repositório de que permite o trabalho colaborativo de profissionais, pesquisadores 
e estudantes ligados a i*, Ele também propõe uma versão adaptada da linguagem, que é 
a adotada neste trabalho. GRL é uma linguagem para modelagem orientada a objetivos, 
especialmente dedicada à análise de requisitos não funcionais. 

Uma das principais variações encontradas nas linguagens refere-se ao uso da 
ligação meio-fim. Em ;* original (Yu, 1995), essa ligação era usada para relacionar um 
objetivo ou uma tarefa a um softgoal. Já na linguagem GRL, meio-fim é usado para ligar 
tarefa com objetivo, tarefa com tarefa, e recurso com tarefa. No Wiki |”, a ligação meio-fim 
é usada somente de tarefa para objetivo. Em Tropos, essa ligação é usada para conectar 
objetivo com tarefa, tarefa com tarefa e tarefa com objetivo. 

A Tabela 3.1, mostra uma comparação das principais dialetos em j*. 


Tabela 3.1 — Principais dialetos de i*. Fonte (Cares, 2012) 


Links/Elementos 


Linguagens | Ator Posição | Agente | Papel | Meio-fim | Decomposição | Contribuição 
i* original Tem Tem Tem Tem G>6, T>G TSs, 
T>6G, TST, Ss5s, 


T5s, T>R, 
T5SR, T+ sS. 
TST. 


1. http://istar.rwth-aachen.de/tiki-index.php?page=i*+Guides&structure=i*+Wiki+Home 
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Wiki i* Tem Tem Tem Tem T>G T>G G>sS, 
TST, T5Ss, 
T5SR, S5Ss, 
T5SsS. BssS. 
Tropos Tem Tem Tem Tem G>T, G>6, Ss5s, 
TST, G5Ss, T>S 
T>6G. G5T, 
S56, 
sS5Ss, 
SST. 
GRL Tem Tem Tem Tem T>6, G>T, Ss5s, 
T5>T, G-6G, S5B, 
T>R. S5T, SSL, 
S56, T5Ss, 
R5ST, T5>B, 
R5G, T>L, 
TST, L5Ss, 
T>6G. L>B, 
L5SL. 


ATabela 3.1, compara as principais variações encontradas nas linguagens i* original, 
Tropos, GRLe Wiki *. Para uma melhor compreensão, as letras têm os seguintes significados 
(R=Recurso, B=Crença, S=Softgoal, T=Tarefa, G=Objetivo, L=Link de Decomposição, 
Contribuição, Meio-fim). A seta é lida da esquerda para a direita. Por exemplo, em Wiki |”, 
o link meio-fim é utilizado somente de recurso para objetivo (T — G), ou seja, um recurso é 
um meio para alcançar um objetivo (Fim), diferentemente de GRL, em que esse link pode 
ser utilizado tanto de uma tarefa (meio) para um objetivo (fim) quanto de uma tarefa (meio) 
para outra tarefa (fim). Nessa tabela, ficaram omitidos os atributos dos links de contribuição 
e as operações tanto dos links meio-fim e decomposição. 

Como pode ser notado pela análise da Tabela 3.1, existem muitas variações entre 
as linguagens. Essas variações fazem com que o uso da linguagem não seja uniforme, 
dificultando a aprendizagem e tornando quase impossível a adoção de i* na indústria. Para 
solucionar esse problema, propomos a interpretação ontológica dos elementos e links da 
linguagem. A ideia não é criar uma nova abordagem, e sim facilitar o entendimento dos 
conceitos dos construtos da linguagem para padronizar o uso de i*. 

Para realizar a interpretação ontológica, foi usada a ontologia UFO, já descrita 
no capítulo 2. UFO tem sido aplicada para avaliar e (re) projetar outras linguagens de 
modelagem conceitual. Por exemplo, (Guizzardi, 2005) propõe um perfil de UML compatível 
com UFO-A. UFO também foi utilizada com sucesso no projeto de uma linguagem para 
desenvolver sistemas de Gestão do Conhecimento (Guizzardi, 2006) e para alinhar objetivos 
e modelos de processo (Cardoso et al., 2010). Finalmente, UFO também foi utilizada para 
a análise de padrões e linguagens de Arquitetura corporativas de TI, tais como RM-ODP 
(Almeida, 2012), Archimate (Azevedo et al., 2011), ARIS (Santos; Almeida; Guizzardi, 
2010). BPMN (Guizzardi, 2011) e REA (Gailly; Geerts; Poels, 2009), entre outros. Em todos 
esses casos, a abordagem ontológica tem se provado útil para explicitar a semântica dos 
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construtos das linguagens analisadas, consequentemente, apontando os possíveis usos de 
tais construtos. Uma vez que os compromissos ontológicos se tornam explícitos, fica muito 
mais fácil para o modelador (iniciante ou não) aplicar a linguagem na prática. 


3.2 — MÉTODO DA ANÁLISE ONTOLÓGICA 


O método que foi utilizado para fazer a análise ontológica é um framework proposto 
por Guizzardi (2005), que tem como objetivo avaliar as linguagens de modelagem. Esse 
framework verifica o quão clara e expressiva uma linguagem é, avaliando também o quanto 
essa linguagem é capaz de representar o estado de coisas (Guizzardi et al., 2013). Em 
geral, o framework se baseia na construção de uma ontologia para descrever o domínio 
conceitual. Tal ontologia é, então, utilizada como modelo de referência para a linguagem, 
analisando-se o quanto a linguagem em questão é capaz de representar os conceitos e 
relações representados na ontologia. Conforme (Guizzardi et al., 2013), a situação ideal 
é aquela em que o metamodelo da linguagem é isomórfico à ontologia de referência, ou 
seja, o caso em que há um mapeamento um-para-um entre os conceitos da linguagem e os 
conceitos definidos na ontologia. 

A Figura 3.1 exemplifica como o método adotado permite a identificação de 
propriedades indesejáveis em linguagens de modelagem, tais como: sobrecarga de 
construto, excesso de construto, redundância de construto e incompletude da linguagem. 


Figura 3.1 - Inconsistências em uma linguagem podem ser detectadas quando o metamodelo da 
linguagem é mapeado para uma ontologia de referência. 


| 
2929, 
excesso de construto 


(A) (B) 


sobrecarga de construto 


| incompletude da ing EE 


(D) 


redundância de construto 
(o 
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Asobrecarga de construto significa que um mesmo construto da linguagem representa 
dois ou mais conceitos ontológicos. De acordo com Guizzardi (2005), “A sobrecarga de 
construto é uma propriedade indesejável de uma linguagem de modelagem, porque ela 
causa ambiguidade. Quando a sobrecarga existe, usuários tem que trazer conhecimento 
adicional não existente na especificação para compreender o fenômeno que está sendo 
representado”. 

Para que a linguagem seja consistente, todo construto da linguagem deve ter uma 
interpretação na conceitualização do domínio. Se a linguagem inclui construtos que não 
tenham um mapeamento na ontologia, os usuários deverão fazer suas próprias interpretações 
sobre esses construtos. Isso pode fazer com que as pessoas se comunicando por meio 
dessa linguagem tenham interpretações não compartilhadas, o que pode gerar problemas 
de interoperabilidade. Ter um construto que não tem mapeamento ontológico é conhecido 
como excesso de construto. A presença do construto extra pode impedir a compreensão da 
especificação. Em outras palavras, a especificação é clara se o leitor consegue relacionar 
os construtos da linguagem a entidades do domínio. Consequentemente, somente as 
entidades do domínio (representados na ontologia) devem ser modeladas com o uso de 
construtos da linguagem. 

Uma linguagem deve possuir apenas um construto para representar cada fenômeno 
do domínio (ou seja, cada entidade da ontologia), evitando a redundância de construto. Se 
houver um mesmo conceito ontológico sendo representado por mais de um construto na 
especificação, há confusão quanto ao significado do modelo. Um leitor pode perguntar a 
si mesmo, por exemplo, se os dois construtos são realmente o mesmo ou se há alguma 
distinção semântica entre eles. Além de adicionar essa dificuldade de compreensão, 
a redundância de construtos adiciona complexidade desnecessária à linguagem de 
modelagem. Em geral, diante da redundância de construtos, modeladores tendem a usar 
os construtos redundantes com um significado ligeiramente diferentes, o que pode não ser 
compreendido pelos leitores do modelo. 

Uma linguagem de modelagem é dita completa se todo conceito do domínio é coberto 
por pelo menos um construto da linguagem. Isso é diretamente ligado à expressividade 
da linguagem de modelagem. Em outras palavras, se a linguagem é incompleta, ela não 
é capaz de representar todos os fenômenos de um dado domínio. O resultado dessa 
incompletude é uma especificação incompleta ou com sobrecarga de construtos, ambos 
indesejáveis por deteriorarem a clareza das especificações produzidas com tal linguagem. 


3.3 - INTERPRETAÇÕES DOS PRINCIPAIS CONCEITOS i* 


Nesta seção, apresentaremos as interpretações ontológicas para os principais 
conceitos do núcleo da linguagem i*, bem como as diretrizes ontológicas propostas a partir 
dessas definições. 
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3.3.1 — Conceitualizando os elementos intencionais de i* 


Conforme descrito no capítulo 2, em UFO, um interessado é representado pelo 
conceito de Agente, definido com um Endurant concreto, que possui Estados Intencionais, 
tais como Crenças, Desejos e Intenções. Um ator em i* é interpretado como um Agente 
em UFO. 

Em UFO, Intenções são estados mentais de agentes que se referem a certas 
Situações (isto é, estados) na realidade. O Conteúdo Proposicional de uma intenção é 
denominado Objetivo. Além disso, uma Ação é um evento deliberadamente realizado por 
um agente para satisfazer sua Intenção. Um objetivo em i* é mapeado para o conceito 
de objetivo em UFO, enquanto uma tarefa em i* é interpretada como uma Ação em UFO. 

Contrário a um Agente, UFO define Objeto como um Endurant Concreto que não 
possui estado intencional e não realiza ações. Um Objeto que participa em uma Ação é 
denominado Recurso. Um recurso em i* é interpretado como um Recurso em UFO. 


3.3.2 Decomposição 


Como objetivos são proposições, não é possível decompor um objetivo em 
recursos ou tarefas, por causa de sua natureza ontológica. Assim, um objetivo só pode ser 
decomposto em subobjetivos. Consequentemente, uma decomposição-AND é interpretada 
como uma conjunção de subobjetivos, enquanto uma decomposição-OR é interpretada 
como uma disjunção de objetivos, conforme apresentado na tabela 3.2. Da mesma forma, 
softgoal, tarefas e recursos só podem ser decompostos em softgoal, tarefas e recursos, 


respectivamente. 


Tabela 3.2 — Diferença entre And-decomposição e Or-decomposição 


And-decomposition GoOGIAGIAGIAG4 
OR-decomposition GoGIWG NY GIN G4 


Portanto, um objetivo G é decomposto por decomposição-AND em G1, G2, G3 e 
G4, se e somente se G é satisfeito quando G1, G2, G3 e G4 são satisfeitos. Entretanto, um 
objetivo G é decomposto por decomposição-OR em G1, G2, G3 e G4, se e somente se G é 
satisfeito por pelo menos uma das situações que satisfaçam G1, G2, G3 e G4. 

O link de decomposição deve ser utilizado, seguindo-se a diretriz ontológica descrita 
a seguir: 


Um link de decomposição pode ser aplicada apenas entre elementos do mesmo tipo. 
Ex: objetivo->objetivo, tarefa->tarefa. 


Diretrizes Ontológicas para a Criação de Modelos i* 


29 


3.3.3 Meio-fim 


Em i*, o link meio-fim é utilizado para conectar, por exemplo, uma tarefa T a um 
objetivo G, significando que a execução de T leva à satisfação de G. Já vimos na seção 
3.2.2 que um objetivo é ligado a subobjetivos a partir do link de decomposição. Assim, 
se permitirmos que, por exemplo, G2 e G3 sejam ligados a G1 usando um link meio-fim, 
estaremos permitindo redundância na linguagem, já que não poderemos distinguir meio-fim 
e decomposição. Como visto na seção 3.2, redundância de construto é algo indesejável, 
pois leva a complexidade da linguagem de modelagem e causa confusão de significado. 
Para evitar isso, o link meio-fim deve ser utilizado de acordo com a seguinte diretriz 


ontológica: 


Um link de meio-fim pode ser aplicada apenas entre elementos de tipos distintos. 


Ex: objetivo->tarefa, objetivo->recurso, tarefa->recurso. 


A Tabela 3.3, mostra quando se deve usar os links meio-fim e Or-decomposição. 


Tabela 3.3 — Or-Decomposição vs. Meio-fim. 


Fim 
T R G sG 
T or-D ae ME ME 
õ R ME or-D ME ME 
G nen ne Or-D == 
sG = ne ce Or-D 


A seguir, descrevemos a interpretação ontológica do link meio-fim para cada relação 
da tabela 3.3 (Guizzardi; Franch; Guizzardi, 2012): 


*— Tarefa é um meio para um objetivo. Em UFO, uma tarefa é interpretada como 
uma ação. E um objetivo é um desejo intencional de um agente, ou seja, é O 
conteúdo proporcional de uma intenção. Portanto, uma tarefa é um meio para 
alcançar um objetivo se a ação leva a uma situação do mundo real que satisfaz 
o objetivo. 


* Recurso é um meio para uma Tarefa. Um recurso em UFO é nada mais do 
que um objeto que participa de uma determinada ação. Um recurso do tipo R 
é um meio para uma tarefa T se para cada instância de T, há a participação de 
um recurso daquele tipo. 


* | Recurso é um meio para um Objetivo. Um recurso do tipo R é um meio para 
um objetivo G se cada ação que satisfaz G tem como parte a participação de 
um recurso daquele tipo. Por definição, fica claro que, mesmo que no modelo 
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não esteja explícita, há sempre uma tarefa (ação em UFO) que tem como parte 
uma participação do recurso R. 


* | Tarefa é um meio para um Softgoal. No caso de softgoal, a crença do agente 
em particular deve ser levada em consideração. Portanto, uma tarefa T é um 
meio para alcançar um softgoal SG (fim) no ponto de vista do agente A, se e 
somente se, uma ou mais execuções de T produzir uma pós-situação que A 
acredita satisfazer SG. 


* | Recurso é um meio para um Softgoal. Um recurso do tipo R é um meio para 
um softgoal SG na perspectiva do agente A se cada ação que A acredita satis- 
fazer SG tem como parte a participação de um recurso daquele tipo. 


Uma outra questão importante em relação ao link Meio-fim se refere ao caso em que 


existem vários meios para alcançar o mesmo fim. Seja, por exemplo, o caso da Figura 3.2. 


( Ter Carro ) 


Fazer leasing de 


Comprar carro caro 


Alugar carro 


Figura 3.2 — O link meio-fim como uma relação XOR 


Nesse caso, o objetivo “ter carro” será atingido se o cliente “comprar carro”, “alugar 
carro” ou “fazer leasing de carro”. Assim, fica claro que o link meio-fim, neste caso, é uma 


relação XOR. Veja, por outro lado, a situação ilustrada na Figura 3.3. 
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Encomendar 
salgados e 


Convidar 
doces 


amigos 


Decorar o 
ambiente 


Figura 3.3 — O link meio-fim como uma relação AND 


Para “organizar uma festa”, a pessoa realiza três tarefas: “encomendar salgados 
e doces”, “decorar o ambiente” e 


convidar amigos”. Nesse caso, o link meio-fim é uma 
relação AND. 


Note que as nas Figuras 3.2 e 3.3, o mesmo link é, assim, usado para indicar duas 
relações distintas, o que é um caso de sobrecarga de construto. Como visto na seção 
3.2, isso deve ser evitado para não gerar ambiguidade. Assim, para diferenciar as duas 


relações, não deixando dúvida para o leitor quanto à interpretação dos modelos, propõe-se 
que o link meio-fim seja anotado como XOR ou AND, como na figura 3.4 


Aniversari 
ante 


Ter carro 


W 
Organizar festa * 
N 
& A Ê 
/ o A AND RE 
N = (e) 
y Comprar sl E 
q carro Fazer leasing de 2 (e) [) 
4 carro 4 + doces 
o | À q 
k o ., Decorar o 
“4 Alugar “x no ambiente 
“a, carro & “E 
“am, ama “- nd “4 


Figura 3.4 — Link meio-fim anotado como (A) XOR e (B) AND. 
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Quando houver mais de um meio para atingir o mesmo fim, os links meio-fim devem ser 
anotados com XOR ou AND, indicando se o fim é atingido se um dos meios for atingido 


(XOR) ou se o fim é atingido apenas se todos os meios forem atingidos (AND). 


3.3.4 Contribuição Make 


Em i*, O link contribuição-Make é aplicado entre uma tarefa e um objetivo, o que 
significa que se a tarefa for executada, então o objetivo é alcançado. Mas se é assim, como 
se pode diferenciar o link Meio-fim do link Contribuição-Make? Em UFO, diferenciamos 
isso olhando para a intenção por trás da execução de uma tarefa. Por exemplo, na Figura 
3.5, temos a seguinte situação: Um ator “Passageiro” executa a tarefa “tomar remédio para 
enjoo” a fim de prevenir-se de ficar enjoado durante a viagem. Como um efeito colateral 
deste medicamento, o passageiro do carro também vai dormir. Ou seja, a tarefa “tomar 
remédio para enjoo” satisfaz o objetivo “prevenir enjoo”, como também satisfaz o objetivo 
“adormecer”. A diferença entre os dois links está na intenção de execução da tarefa, no 
entanto, a tarefa satisfaz dois objetivos, um intencionalmente e o outro sem a intenção. 


Prevenir enjoo 


Adormecer 


Make 


Tomar remédio 
para enjoo 


Figura 3.5 — Utilização do link Contribuição Make. 
Em UFO, cada tarefa está associada a uma intenção cujo conteúdo proposicional é 
um objetivo. Ou seja, ao executar uma tarefa específica, almeja-se satisfazer um objetivo 


específico. Em i*, a associação entre a tarefa e objetivo, neste caso, é feito pelo link Meio- 
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fim (Por exemplo, executar a tarefa “tomar remédio para enjoo” com o meio para “prevenir 


enjoo”. Por outro lado, esta mesma tarefa também pode gerar alguns outros objetivos. 


Nesse caso, utiliza-se o link contribuição-Make (Por exemplo, ao executar a tarefa “tomar 


remédio para enjoo” como meio para “adormecer”. 


O uso do link de contribuição-Make deve seguir a diretriz ontológica abaixo: 


Tarefa T --- contribuição-Make - objetivo G para um ator A, se e somente se, 
IE 
2. 
&, 


Ao optar por realizar T, A não teve a intenção de alcançar o objetivo G, 
Realizar T causa uma situação S e 


Situação S satisfaz G 


Para softgoal G, substituir 2 e 3 por 


A acredita que Realizar T causa uma situação S e 


A acredita que Situação S satisfaz G 


3.3.5 Contribuição Help 


Ao contrário do link Contribuição-Make, o link Contribuição-Help não conduz a 


realização plena do objetivo final, e sim à realização parcial do objetivo final. Por exemplo, 


a Figura 3.6 apresenta o caso de um ator (participante do caise) que realiza uma ação 


“Beber Aigua de Valência” para alcançar o objetivo “Comemorar o sucesso da conferência”. 


Esta mesma tarefa também contribui para outro objetivo, “Ter boas ideias para os próximos 


artigos”. Porém, este objetivo é atingido parcialmente. 


Comemorar O sucesso 
da conferência 


Ter boas ideias 


para os próximos 
artigos 


Help 


Beber Aigua de 
Valência 


Figura 3.6 — Utilização do link Contribuição Help 
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O link contribuição-Help deve ser utilizado de acordo com a seguinte 
diretriz ontológica: 


Tarefa T --- contribuição-Help - objetivo G para um ator A, se e somente se, 
1. Realizar T causa uma situação S e 


2. S é parte da situação S' que satisfaça G. 


* Para softgoal G, substituir 2 por 


2. Sé parte da situação S que A acredita que satisfaz G 


3.3.6 Contribuição Break 

A Figura 3.7 mostra um ator condutor “Motorista”, que executa a ação “tomar vinho”, 
a fim de satisfazer o objetivo “aproveitar o jantar”. No entanto, isso desabilita outro objetivo 
seu, o de “dirigir respeitando as leis”. Em ;*, isso é feito a partir do link Contribuição-Break 
ligando a tarefa “tomar vinho” e o objetivo “dirigir respeitando as leis”. 


Motorista Aproveitar o 
jantar 


Dirigir 
respeitando 
as leis 


Break 


Figura 3.7 — Utilização do Link Contribuição Break 


Neste exemplo, existem duas situações de conflito, que o ator não pode obter ao 
mesmo tempo. Uma tarefa desabilita um objetivo, se e somente se, a tarefa traz o mundo 
a um estado tal que, enquanto esse estado persistir, nenhuma ação que pode satisfazer o 
objetivo pode eventualmente ser realizada. Conforme a Figura 3.7, a tarefa “tomar vinho” 
desativa todas as ações que possam satisfazer o objetivo “dirigir respeitando as leis”. 


O link contribuição-Break deve ser utilizado de acordo com a seguinte diretriz 
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ontológica: 


* Para softgoal G, substituir 2 por 


Tarefa T ---contribuição-Break - objetivo G para um ator A, se e somente se, 
1. Realizar T provoca uma situação S e 


2. S desativa qualquer Task Tº que satisfaça G. 


2. S desativa qualquer Task T' que A acredita que satisfaça G 


3.3.7 Contribuição-Hurt 


No exemplo da Figura 3.8, temos o planejador de conferência, cujo objetivo principal 


é “não gastar dinheiro com o palestrante”. Suponha que esse objetivo possa ser atingido se 


os objetivos “convidar um palestrante gratuito” e “obter patrocínio para o palestrante” (ver 


decomposição-OR) sejam satisfeitos, ou seja, os subobjetivos sejam alcançados. A tarefa 


“convidar um palestrante profissional” desabilita o objetivo “convidar um palestrante gratuito” 


(contribuição-Break) e, consequentemente, contribuir negativamente (contribuição-Hurt) 


para o objetivo principal “não gastar dinheiro com o palestrante”. Note que esse objetivo 


ainda pode ser atingido pela tarefa “convidar palestrante patrocinado”. 


Não gastar 
dinheiro com o 
palestrante 


Convidar ur 
palestrante gratuito 


Hurt 


Break 


Convidar ur 
palestrante 
profissional 


Obter patrocínio 
para o palestrante 


Convidar 
palestrante 
patrocinado 


Adiquirir: 
patrocinio de 
parceiros 


Figura 3.8 - Utilização do link Contribuição-Hurt 
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O link contribuição-Hurt deve ser utilizado de acordo com a seguinte diretriz 
ontológica: 


* Tarefa T ---contribuição-Hurt - objetivo G para um ator A, se e somente se, 


3. G é satisfeito por G1 ou G2 e 
4. Aexecução de T desabilita G1 


* Para softgoal G, substituir 2 por 


2. A acredita que a execução de T desabilita G1 


3.4 — Considerações Finais do Capítulo. 


O framework i* possui vários dialetos e variantes, o que dificulta o aprendizado da 
linguagem e sua adoção na indústria. Para solucionar esse problema, descreve-se, neste 
capítulo, um conjunto de diretrizes de modelagem. Essas diretrizes foram criadas com base 
em uma interpretação ontológica de i*, usando a ontologia de fundamentação UFO. Além 
disso, utilizamos o framework proposto por Guizzardi (2005), que tem como objetivo avaliar 
as linguagens de modelagem, evitando a sobrecarga, a redundância, a falta e o excesso 
de construtos. 

Espera-se que, seguindo as diretrizes ontológicas aqui descritas, os modeladores 
possam criar modelos em i* de melhor qualidade. É preciso, porém, confirmar se essa 
intuição é verdadeira a partir de uma validação das diretrizes ontológicas. Esse é o objetivo 
do próximo capítulo desta dissertação, que trata de um estudo empírico realizado com este 
fim. 
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CAPÍTULO 4 


VALIDANDO O USO DE DIRETRIZES ONTOLÓGICAS NO 
DESIGN DE MODELOS i* USANDO PROTOCOLO DE 
EXPERIMENTO 


Este capítulo trata do núcleo principal da dissertação. A seção 4.1 será abordada uma breve 
introdução do capítulo e sobre o framework utilizado no experimento; a seção 4.2 será 
apresentado o framework utilizado no experimento; a seção 4.3 será abordado o experimento 
para validação das diretrizes ontológicas para construção de modelos i*; a seção 4.4 será 
realizado a aplicação do experimento; apresentado o resultado do experimento aplicado; a 
seção 4.5 será apresentado a coleta de dados para a aplicação 1 do experimento; a seção 
4.6 será apresentado a coleta dos dados para aplicação 2 do experimento; a seção 4.7 
descreve a análise dos dados, tanto descritiva quanto a estatística; abordados os trabalhos 
relacionados ao nosso trabalho de dissertação. E por fim, a seção 4.8 é apresentada as 
considerações finais do capítulo. 


4.1 - INTRODUÇÃO 


Toda pesquisa realizada ou conhecimento científico deveria ser baseada em algum 
tipo de experimento. Hoje o estudo empírico, é uma forma eficiente de provar a eficácia 
de uma nova abordagem ou pesquisa realizada. Entretanto, muitos artigos, trabalhos ou 
pesquisas na área da computação tem poucos ou nenhum estudo empírico comparado 
à área médica. Para Vokc (2002), um raciocínio simples nos leva a esperar que uma 
ciência ideal, seria ter pelo menos um conjunto de observações empíricas para cada teoria 
proposta. Conforme Travassos (2002), a experimentação é o núcleo do processo científico, 
ou seja, é através dos experimentos que se verificam as teorias e exploram os fatores 
críticos para que as teorias possam ser formadas e corrigidas. 

Uma categoria muito importante do estudo empírico é o experimento, para (Sjoberg 
et al., 2005). O experimento é a realização de um método científico que visa identificar a 
relação de causa e efeito. O experimento é uma atividade que manipula variáveis, observa 
outras variáveis, com o objetivo de realizar a medição de um fenômeno de interesse, de 
forma precisa e confiável. 

Neste capítulo iremos descrever o experimento realizado para validar as diretrizes 
ontológicas para criação de modelos i*, apresentadas no capítulo 3. O objetivo do 
experimento é colher indicações sobre o uso das diretrizes ontológicas na elaboração de 
modelos em domínios específicos apresentados nos Apêndices E, G e |. As hipóteses da 
pesquisa é “as diretrizes ontológicas não são percebidos como útil pelo modelador”. Para 
nos guiar no design do experimento, utilizamos o framework proposto por (Kochanski, 
2009), adaptando-o para as necessidades do nosso trabalho. O framework adaptado pode 
ser encontrado nos Apêndices A e B. O Framework completo pode ser encontrado em 
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(Kochanski, 2009). 


4.2 FRAMEWORK ADAPTADO 


Nessa seção será apresentado o framework adaptado (Apêndice A e B) do trabalho 
realizado por (konchanski, 2009). De acordo com konchanski (2009), o framework foi 
desenvolvido com o objetivo de facilitar o trabalho de pesquisadores, além de incentivar 
a realização de avaliações na área de engenharia de software. Ele foi concebido para 
realização de estudos empíricos sobre os efeitos de aprendizagem pelo uso de jogos 
educacionais voltados para a área de Engenharia de Software. 

Em nosso trabalho o framework (pode ser visto nos Apêndice A e B), foi adaptado 
em duas partes, a primeira parte trata dos elementos que devem ser observados no 
momento da definição do experimento, o planejamento do experimento, os procedimentos 
que serão realizados no momento que o experimento for aplicado. A segunda parte trata 
dos elementos a serem observados no momento da análise e interpretação dos dados. 
Essas adaptações têm como base o processo de realização de experimento descrito no 
capítulo 2. 

A primeira parte do experimento se divide em quatro subpartes: (i) Informações 
Preliminares; (ii) Planejamento detalhado do experimento — Objeto/Unidade de estudo; 
(ii) Abordagem da pesquisa; e por fim, (iv) .Planejamento detalhado do experimento — 
Instrução do Design. 

Em informações preliminares é descrito um breve resumo do experimento. Nesse 
resumo deve conter um contexto histórico em torno do problema, o que já foi realizado 
anteriormente em relação ao problema e quais questões são foco da pesquisa. Também 
deve conter um objetivo geral da realização do experimento e objetivos específicos que se 
pretende chegar. 

Em Planejamento detalhado do experimento — Objeto de estudo, relaciona-se aos 
elementos referentes ao fator, ou seja, variáveis independentes referem-se à entrada do 
processo de experimentação, apresentando a causa que afeta o resultado do processo de 
experimentação, definição dos participantes, a estratégia de seleção de grupos, definindo 
de que forma será feito a montagem do grupo de controle e grupo experimental, formulários 
e definição da condição para que os participantes possam participar do experimento. 

Em Abordagem da pesquisa, relaciona-se aos elementos referentes da estratégia da 
pesquisa, se ela será qualitativa ou quantitativa (ver definição na seção 2.3), e, a forma de 
realização do experimento, que pode ser, in-vitro, in-vivo, in-virtuo, in-silicio (ver definição 
na seção 2.3). 

E por fim, planejamento detalhado do experimento — instrução design, é a parte do 
framework que descreve passo a passo a execução do experimento. Portanto, é nele que 
definimos o momento que os participantes irão preencher os formulários, qual o momento 
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que irá iniciar a primeira apresentação, quanto tempo os participantes terão para fazer 
as atividades referentes ao experimento. Essa parte é fundamental para o sucesso do 
experimento, por conter de forma detalhada como será executado o experimento, além de 
permitir que outros pesquisadores possa refazer o seu experimento de acordo com a sua 
execução.Como pode ser visto o resultado na Tabela 4.1. 


Tabela 4.1 — Primeira parte do framework adaptado. 


Informações Preliminares 


Resumo 


(dece conter um breve resumo do estudo, o que já foi feito sobre o estudo, e o que você pretende 
fazer sobre o estudo(Finalidade)) 


Objetivos 
Geral (descrição do objetivo geral do experimento) 
Específicos (descrição dos objetivos espécificos do experimento) 


Research Questions and Metrics 


(descrição sobre questão de pesquisa e métricas do experimento) 


Plano Detalhado do Experimento 


Objeto/Unidade de Estudo 


(descrição do objeto, unidade de estudo) 


Fator(es) Alternativa dos fatores 


(Fator(es) de estudos) | (Alternativa dos fatores de estudos) 


Sujeitos/Particpantes do Experimento 


(descrição dos participantes do experimentos) 


Seleção do Grupo de | (descrição da estratégia utilizada para a seleção dos grupos e forma de 
Estratégia atrbuição) 


Formulários / Conteúdo 
Termos / Material 
[ ] Termo de (descrição do formulário do participante deve assinar e concordar em 
Consentimento participar do experimento) 
[ ] Formulário do (Formulário de descrição para os participantes preencher com dados do 


Perfil do Particpante perfil) 


[ | Questionário de (descrição da forma do questionário de avaliação sobre experimento) 
Avaliação 


[ | Material de Apoio | (descrição da forma do material de suporte no experimento) 


Participation Pre- | | (descrição do pré-requisitos(os participantes devem ter aulas/formação 


conditions prévia, etc.) 
Research Approach 
[ | Qualitativa (descrição da justificativa para o uso da estratégia) 
[ |] Quantitativa (descrição da justificativa para o uso da estrtégia) 
Method Justification 
[ Jin-vitro (descrição da justiicativa para o uso do método) 
[ Jin-vivo (descrição da justiicativa para o uso do método) 
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[ Jin-virtuo (descrição da justiicativa para o uso do método) 


[ Jin-silico (descrição da justiicativa para o uso do método) 


Plano Detalhado do Experimento 


Instrução de Design 


(descrição que ocorrem nas aulas/formação dos participantes) 


A segunda parte do framework se divide em quatro subpartes: (i) plano análise do 
resultado; (ii) avaliação de validade; (iii) conjunto de redução dos dados; e por fim, (iv) 
especificação da operação do experimento. 

No plano análise do resultado, é abordado quais as hipóteses serão investigadas 
pelo experimento, quais as métricas serão abordadas para a análise das hipóteses, quantas 
variáveis dependentes, e que tipos de ameaças serão tratadas no experimento. Qual o tipo 
de calculo será utilizado para aceitar ou negar as hipóteses. Essa parte depende muito da 
etapa de operação, é através da coleta de dados e sua interpretação que chegamos a uma 
conclusão. 

Na etapa de avaliação de validade, tem como objetivo avaliar partes ou resultado 
em geral com propósito de validar os resultados obtidos em um experimento. Uma das 
ameaças que envolve o experimento é a influência do próprio pesquisador que tem seu 
interesse próprio. Já na etapa de conjunto de redução dos dados, como já mencionado 
em capítulos anteriores, tem como objetivo eliminar pontos de dispersão. Ou seja, eliminar 
erros em um conjunto de dados que pode acontecer de forma de erro sistemático. 

E por fim, a especificação da operação do experimento, é abordada qual material 
(computador, datashow, laboratório, etc) a ser usado na execução do experimento. De que 
forma garantir dos participantes o seu comprometimento com o experimento, qual a melhor 
maneira para realizar a coleta de dados dos participantes e seu processamento, como a 
coleta deverá ser realizada, ou seja, de forma automática, de forma manual por pessoas. 
Além de, descrever que forma os dados processados para analise estejam fidedignos 
aos dados coletados. Descrever como será o ambiente, principalmente se o experimento 
não for in-vivo, ou seja, a execução do experimento não será o natural ou real, devendo 
ser conservado na medida do possível. E informações sobre validade e conformidade, 
garantindo que os procedimentos planejados para o experimento sejam seguidos, evitando 
eventuais desvios que possam influenciar os dados coletados. Conforme pode ser visto o 
resultado na Tabela 4.2. 
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Tabela 4.2 — Segunda parte do framework adaptado. 


Plano de Análise dos Resultados 


Hipóteses Descrição 
Ho (descrição da hipótese) 
Hi (descrição da hipótese) 

Hipóteses Metricas 
HO (descrição da métrica da hipótese) 
Hi (descrição da métrica da hipóteses) 
Variáveis Dependentes Descrição 
Variável 1 (justificativa do uso da variável de controle) 
Variável 2 (justificativa do uso da variável de controle) 


Avaliação da validade 


Ameaça Descrição 

Ameaça 1 (descrição da ameaça) 
Ameaça 2 (descrição da ameaça) 

Parâmetros Justificativa 

Populacionais 

[ ] Parametric (descrição) 
[ ] Não-parametric (descrição) 

Used Test Justificativa 
(descrição do uso do (descrição) 
teste) 


Conjunto de Dados de Redução 


(Descrição da estratégia a ser utilizada para a análise e uma redução do conjunto de dados) 


Especificação da Operação do Experimento 


Material (descrição dos materiais usados no experimento) 
Compromisso (descrição do compromisso) 

Dados coletados (descrição dos dados coletados) 

Ambiente (descrição do ambiente em que ocorreu o experimento) 
Validade (descrição da validade) 

Conformidade (descrição da conformidade) 


4.3 APLICAÇÃO DO EXPERIMENTO 


O processo da realização do experimento se deu com base no framework 
apresentado na seção anterior. De forma breve, o experimento visa validar as diretrizes 
ontológicas utilizadas pelos participantes no desenvolvimento de modelos i*, verificando se 
as diretrizes ontológicas são úteis ou não no desenvolvimento de modelos i*. As hipóteses 
de pesquisa são: 


* HO: As diretrizes ontológicas não são percebidas como úteis pelo modelador. 


*— H1:As diretrizes ontológicas são percebidas como úteis pelo modelador. 
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*. H2: O uso das diretrizes ontológicas não acelera o processo de criação de 
modelos i*. 


*-— H3: O uso das diretrizes ontológicas acelera o processo de criação de modelos 


it 


A Tabela 4.3 mostra as hipóteses e métricas em relação as hipóteses no plano de 


análise dos resultados. 


Tabela 4.3 — Parte do Framework, Plano de análise dos resultados. 


Plano de Análise dos Resultados 
Hipóteses Descrição 
HO As diretrizes ontológicas não são percebidas como úteis pelo modelador 
Hi As diretrizes ontológicas são percebidas como úteis pelo modelador. 
H2 O uso das diretrizes ontológicas não acelera o processo de criação de 
modelos |*. 
H3 O uso das diretrizes ontológicas acelera o processo de criação de modelos i* 
Hipóteses Metricas 
HO Dada pelos particpantes a respeito da não utilidade das orientações 
ontológicas 
H1 Dada pelos participantes quanto à utilidade das orientações ontológicas 
H2 Tempo despendido no desenvolvimento de modelos concebidos sem o uso 
das diretrizes ontológicas; 
H3 Tempo despendido no desenvolvimento de modelos concebidos com o uso 
das diretrizes ontológicas. 


O experimento se baseia em uma estratégia quantitativa, em que os dados serão 


analisados a partir de métodos estatísticos e a experimentação utiliza o método jin vitro, 


ou seja, o experimento foi realizado em um ambiente controlado como pode ser visto na 


Tabela 4.4. 


Tabela 4.4 — Parte do framework, estratégia da pesquisa e método de experimentação. 


Abordagem de Pesquisa 


[ ] Qualitativa 


[X] Quantitativa 


Para validar se as orientações ontológicas são úteis ou não no 
desenvolvimento de modelos i*, e verificar se os participantes são 
capazes de utilizar as orientações ontologicas. 


Método Justificativa 
[X ]in-vitro Desenvolvido em um ambiente controlado 
[ Jin-vivo Desenvolvido em um ambiente real. 
[ Jin-virtuo Desenvolvido através de uma simulação de computador. 
[ Jin-silico Desenvolvido com modelos matemáticos sem interação humana. 
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O experimento foi realizado em duas instituições de ensino superior denominadas aplicação 
1 e aplicação 2, com cinquenta e cinco estudantes ao todo. Os participantes são alunos dos 
cursos de Ciência da Computação, Análise e Desenvolvimento de Sistemas, Mestrado em 
Informática e Doutorado em Ciência da Computação. Como pode ser visto na Tabela 4.5. 


Tabela 4.5 — Parte do framework — Sujeitos/participantes do experimento. 


Sujeitos / Participantes do Experimento 


Os participantes são estudantes de duas universidades no Estado do Espirito Santo-ES, 
alguns alunos do curso de Análise e Tecnologia de Sistemas e graduação de Engenharia e 
Ciência da Computação, mestrado e doutorado. 


No primeiro momento os participantes receberam informações sobre o experimento e 
sua importância no sucesso da pesquisa, além de ser informado que a participação deveria 
ser livre e que, a qualquer momento, cada um poderia deixar de realizar o experimento. 
Logo depois, todos os participantes assinaram um termo de concordância, disponível 
no apêndice C. Não foi estipulado requisito mínimo para participação do experimento. 
Para que tivéssemos informação sobre o nível de conhecimento dos participantes sobre 
modelagem de objetivos em particular, com a linguagem i*. Os participantes preencheram 
um questionário de perfil dos participantes, que pode ser visto no Apêndice D e conforme 
a Tabela 4.7. 

O experimento teve como objeto de estudo dois modelos desenvolvidos, utilizando 
i*, representando duas situações diferentes, a primeira situação é referente a “Fabricante de 
equipamentos eletrônicos”, e a segunda situação é referente ao “Organizador de um mercado 
de Natal”, ambas as situações podem ser vistas nos apêndices E e G, respectivamente. O 
fator do experimento é o construtor da linguagem i* cujo uso normalmente geram confusão 
ou dúvida, e a alternativa é fazer o uso ou não das diretrizes ontológicas, ou seja, selecioná- 
los intuitivamente (pré-teste) ou se o uso das diretrizes ontológicas (pós-teste) ajudam, 
efetivamente na seleção dos construto correto. Como pode ser visto na tabela 4.6. 


Tabela 4.6 — Parte do Framework — Objeto de estudo, fatores e alternativa dos fatores. 


Plano Detalhado do Experimento 
Objeto/Unidade de Estudo 
Desenvolvendo modelos de objetivos utilizando i* 


Fator(es) Alternativa dos Fatores 


Construtor da linguagem |* Fazendo o uso ou não das diretrizes ontológicas. 


No objeto de estudo, cada participante tem que completar, preenchendo as lacunas 
com o elemento ou relação correta a ser usada em cada caso. Portanto, os participantes 
devem marcar com um “X”, qual a opção correta entre os elementos e links de ligação. A 
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Figura 4.1 ilustra parte do diagrama baseado na descrição da situação “Organizador de 
um mercado de Natal”, esse diagrama completo e a descrição da situação “Organizador 
de um mercado de Natal”, encontra-se no Apêndice G. Para cada lacuna, há entre duas 
e mais possibilidades, trazendo, como alternativa, construtos de i*. Na Figura 4.1, temos 
um elemento (Provide gift wrapping solution) ligado por duas linhas tracejadas na cor azul 
nos elementos (Organize wrapping stand) e (Allow vendors to wrap gifts). Os participantes 
tinham que identificar qual elemento representa (Provide gift wrapping solution) escolhendo 
entre, Goal ou Task. E escolher entre OR-Menas-End e OR-Decomposition as ligações 
entre os elementos, de modo a verificar se os participantes conseguem selecioná- 
los intuitivamente (pré-teste) ou se o uso das diretrizes ontológicas (pós-teste) ajuda, 
efetivamente, na seleção do construto correto. 


event 


Provide gift 


( ) OR-Means-End 
( ) OR-Decomposition 


( )Break Contributioã 
( ) Means-End k 
( )Help Contributign 


Means-End Ê 
Help Contribution" 


| 


Have 
Less effort 


14. ( ) Break Contribution 
( ) Means-End 
( ) Help Contribution 


Figura 4.1 - Parte do modelo i*. 


Em seguida ao preenchimento do formulário, cada participante respondeu a um 
questionário sobre o modelo analisado, justificando a escolha de cada elemento ou 
relação. A Figura 4.2 ilustra uma questão do formulário de atividades. O objetivo desse 
formulário é fornecer subsídios para que possamos compreender o que levou à escolha de 
cada construto, por exemplo, no pós-teste, se o participante tinha em mente uma diretriz 
ontológica, ao realizar a escolha por determinado construto. Em outras palavras, caso 
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o participante escolhesse assinalar com um “X” a opção “Goal” na segunda questão do 
diagrama representando na Figura 4.2. O participante deveria responder no questionário de 
atividade o motivo pelo qual o levou a assinalar essa opção. O questionário de atividades 
completo pode ser visto no apêndice G. 


UFES (Universidade Federal do Espírito Santo) 
NEMO (Ontology & Conceptual Modeling Research Group) 
Ontological Guidelines for the Use of |* Intentional Elements and Links 
Um Estudo empírico 


Atividade 2 — Escolha adequadamente o elemento e links “em um determinado 
modelo &* 


Questionário de Atividades 


EE favor, E UG a razão para a escolha de um determinado elemento ou link * nos seguintes 
casos a partir do E UG 


Figura 4.2. Parte do Questionário de Atividades. 


O experimento foi realizado em dois passos, pré-teste e pós-teste, conforme 
detalhado no apêndice A. Na atividade de pré-teste, os participantes assistiram a uma 
apresentação, introduzindo a linguagem i* e provendo orientações de uso do Wiki |”, 
um wiki que reúne informações publicadas pela comunidade de desenvolvimento desta 
linguagem (o conteúdo da apresentação pode ser encontrado no apêndice L). Após a 
apresentação, os participantes fizeram a primeira atividade (pré-teste) referente a uma 
situação envolvendo um sistema de Call Center (apêndice E). Em seguida, preencheram 
o questionário de atividades já mencionado anteriormente, justificando a escolha de cada 
elemento ou link de ligação (apêndice F). Durante essa atividade, todos os participantes 
tinham, em mãos, a impressão dos slides da apresentação realizada, bem como a descrição 
da situação para qual o modelo que tinham que completar foi criado. 

Depois da realização da primeira atividade, os alunos foram divididos em dois grupos 
de forma aleatória, denominados de grupo A e grupo B. Essa divisão se deu através de 


1. http://istar.rwth-aachen.de/tiki-index.php?page ref id=67 
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sorteio, tendo sido estabelecido um grupo de controle (grupo A) e um grupo experimental 
(grupo B). Como pode ser visto na tabela 4.7. 


Tabela 4.7 — Parte do framework — Estratégia da seleção de grupos, formulários, termos e material. 


Estratégia da Seleção dos the participants fill in two online forms: the Term of Consent 
grupos and the Participant Profile Form. The participants are randomly 
selected to the control and experiment groups The control group 
is formed by half of the participants who will not receive any 
instruction regarding the ontological guidelines, serving as basis 
for comparison with the experiment group. The experiment group 
will learn how to use the ontological guidelines through an activity 
during the experiment tasks, they will be simply called groups A 
and B, respectively. 


Forms / Terms / Material Content 


[X] Term of Consent Aims at formalizing the participant's agreement in voluntarily 
taking part in the experiment tasks. 


[X] Participant Profile Form Aims at obtaining from the participant, a set of data that will assist 
in the interpretation and analysis of the experiment results. 


[X] Evaluation Questionnaire Aims at obtaining information regarding how the ontological 
guidelines assist the participant, as well as his/her opinion 
regarding the usefulness of these guidelines. 


[X] Supporting Material Aims at conveying the participants with information about the 
experiment and about the use of the ontological guidelines. 


Na atividade de pós-teste, após a divisão dos grupos, os participantes do grupo A se 
deslocaram a outra sala, juntamente a outro pesquisador para realizar a segunda atividade 
do experimento, que é composta por uma situação “Organização de um mercado de natal” 
com seu respectivo diagrama do modelo criado (apêndice G), e posteriormente respondeu 
ao questionário de atividades (apêndice H). Para a realização da atividade, o grupo A 
recebeu as orientações da Wiki ;* e o conteúdo da aula sobre essas orientações (apêndice 
K), e respondeu a seguinte questão: “Por favor, forneça a razão para a escolha de um 
determinado elemento intencional ou link ;* nos seguintes casos a partir do diagrama”. 
Como resposta o participante teria que informar qual o real motivo para a escolha do 
elemento ou link de ligação das 14 lacunas apresentadas no diagrama. Os participantes do 
grupo B assistiram a uma apresentação sobre as diretrizes ontológicas (apêndice M), e em 
seguida realizaram a segunda atividade do experimento, que é composta por uma situação 
“Organização de um mercado de natal” com seu respectivo diagrama do modelo criado 
(apêndice 1), e posteriormente responderam ao questionário de atividades (apêndice J). 
Para a realização da atividade, o grupo B recebeu as orientações das diretrizes ontológicas, 
juntamente com o conteúdo da aula (apêndice L). E respondeu as seguintes questões: (A) 
Por favor, forneça a razão para a escolha de um determinado elemento intencional ou 
link ;* nos seguintes casos a partir do diagrama. Como resposta os participantes teriam 
que informar qual o real motivo para a escolha do elemento ou link de ligação das 14 
lacunas apresentadas no diagrama; (B) As orientações ontológicas (aprendidas na 
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segunda apresentação) são úteis na construção de modelos i*? Os participantes tinham as 
seguintes respostas: Muito útil/Um pouco útil/Indiferente/Não muito útil/Não é útil a todo, 
além de um campo para fazer comentário na sua escolha; (C) Faça uma comparação das 
orientações do Wiki |* com as diretrizes ontológicas aprendidas na segunda apresentação. 
Os participantes tinham as seguintes respostas: Melhor/Mesma qualidade/Pior. 

O design do experimento se deu dessa forma para que pudéssemos analisar a 
diferença (em termos de erros e acertos) entre os participantes do grupo experimental, que 
usou as diretrizes ontológicas na escolha do construtor correto em cada caso do formulário, 
e o grupo de controle, que teve acesso apenas às orientações do guia disponível no 
Wiki i*, Os termos de erros e acertos, são as nossas variáveis dependentes, pode ser 
vista na Tabela 4.8. Essas variáveis são medidas para cada pergunta, comparando cada 
resposta no diagrama correspondente ao modelo. Se elas são iguais, então a resposta 
está correta, caso contrário, a resposta está errada (Por exemplo, para demonstrar como 
analisamos a questão, considere a Figura 4.1, na segunda questão, no qual o participante 
tinha que escolher entre duas opções, Goal e Task, caso ele assinala-se Task o resultado 
era comparando com o diagrama correspondente que tem como resposta correta Gol, 
automaticamente a questão é considerada errada). Como todos os participantes já tinham 
feito uma atividade no pré-teste usando apenas as orientações do guia disponível do Wiki 
i*, podemos comparar, também, a diferença de resultado no grupo B, realizando atividades 
com e sem o uso das diretrizes ontológicas, para comprovar a hipótese de que elas 
são realmente úteis. Podemos analisar, ainda, se o resultado se mantém estável entre 
os participantes que somente usaram as orientações do Wiki /*, já que, se os resultados 
forem muito distintos, isso pode ser atribuído ao uso de uma situação no pós-teste que os 
participantes acharam mais fácil do que a anterior. 


Tabela 4.8 — Parte do framework, variável dependente 


Variáveis Dependentes Descrição 
Variável 1 Notas dos modelos dos participantes no pré-teste 
Variável 2 Notas dos modelos dos participantes no pós-teste 


Para capturar a impressão dos participantes sobre as orientações de modelagem 
fornecidas durante o experimento, foram incluídas perguntas no questionário de atividades, 
nos dois passos do experimento. No pré-teste, a pergunta era a seguinte: (i) As orientações 
do Wiki i* (vistas na primeira apresentação) são úteis na construção de modelos ;*? As 
respostas possíveis eram: muito útil/um pouco útil/indiferente/não muito útil'não é útil a 
todo. Para o grupo experimental (grupo B), no pós-teste, foram incluídas as seguintes 
perguntas: (ii) As orientações ontológicas (aprendidas na segunda apresentação) são úteis 
na construção de modelos |*? Essa pergunta tinha, como resposta, a mesma apresentada 
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em (i). (iii) Faça uma comparação das orientações do Wiki i*e as orientações ontológicas 
aprendidas na segunda apresentação. Essa última pergunta tinha como resposta: melhor/ 
mesma qualidade/pior. 


4.4 COLETA DOS DADOS PARA APLICAÇÃO 1 DO EXPERIMENTO 


As mesmas atividades e questionários foram utilizados em ambas as aplicações do 
experimento. Para realizar a captura do perfil do participante, foi utilizado o questionário 
que se encontra no apêndice D. 

Na aplicação 1, os participantes, em sua maioria, eram alunos de graduação em 
Ciência da Computação e Engenharia da Computação. No total de 25 participantes, 17 
estavam cursando graduação, 7, mestrado em Informática e 1, doutorado em Ciência da 
Computação. Cada grupo teve 12 participantes (o grupo B tinha ficado com um membro a 
mais, que desistiu da realização do pós-teste, o que, portanto, deixou os dois grupos com o 
mesmo número de participantes). Em relação ao tempo de experiência em modelagem de 
objetivos, os dois grupos também se encontram equilibrados. Tanto no grupo A quanto no 
grupo B, havia um participante entre 1 a 3 anos de experiência em análise de objetivos e |*, 
enquanto os demais declararam não ter experiência nessa área. Aqueles que declararam 
ter experiência de 1 a 3 anos informaram que essa experiência foi adquirida em disciplinas 
optativas na graduação, leitura de artigos, experimentos e atividades realizadas em sala 
de aulas. 

Como objetivo de subsidiar a análise sobre aspectos importantes ligados ao resultado 
do experimento, optamos por apresentar os dados coletados em quatro subseções: 4.4.1 
concentra-se no número de acertos por participante, com o objetivo de fornecer subsídio 
para a análise da performance dos participantes dos dois grupos nas atividades propostas 
(buscando negar a hipótese HO e confirmar a hipótese H1); 4.4.2 focaliza o tempo de 
resposta dos participantes nas atividades no pré-teste e no pós-teste, para ajudar-nos a 
entender se o uso das diretrizes ontológicas leva a um retardo na escolha pelo elemento/link 
correto (procurando confirmar a hipótese H2); 4.4.3 apresenta dados relativos ao número 
de acertos por questão respondida, para permitir a análise das questões que trouxeram 
maior grau de dificuldade para os participantes do experimento; 4.4.4 traz a avaliação da 
percepção dos participantes quanto a utilidade das diretrizes ontológicas e de como se 
comparam às orientações do Wiki i*. 


4.4.1 Dados quanto ao Número de Acertos por Participantes 


Para viabilizar a comparação da performance dos participantes nas atividades do 
experimento com e sem o uso das diretrizes ontológicas, é importante analisar o número 
de acertos por participante. A Tabela 4.9 mostra o número de acertos por participante para 
cada grupo, nas atividades de pré-teste e pós-teste da aplicação 1 do experimento. 
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Tomando os dados na Tabela 4.9, ao compararmos o total de acertos das colunas 
de pré-teste dos dois grupos, observamos que usando somente as orientações do Wiki i*, 
ambos os grupos ficaram equilibrados, ou seja, obtiveram 50% de acertos por participantes. 
Já ao compararmos o total de acertos das colunas de pós-teste, percebemos que, em 
porcentagem, o grupo experimental teve 75% de acertos em contraste a 25.% obtido pelo 
grupo de controle. Portanto, o grupo experimental (Grupo B), grupo que utilizou as diretrizes 
ontológicas, foi nitidamente superior ao grupo de controle (Grupo A), que não teve acesso 


as diretrizes ontológicas. 


Tabela 4.9 — Número de acertos por participante para cada grupo (Aplicação 1). 


Participantes do Grupo de Controle Participantes do Grupo Experimental 
ld Participante Pré-teste Pós-teste ld Participante Pré-teste Pós-teste 

AO1 4 7 Bo2 3 8 

AOS 4 8 B04 3 8 

AOS 5 8 Bo6 4 10 

AO7 5 8 Bog 4 un 

AO8 5 9 B1o 5 nu 

A12 5 9 B13 5 ti 

A16 6 9 B1i4 5 12 

A17 6 9 B15 o 12 

A19 6 10 B18 7 12 

A2Z0 7 10 B21 7 12 

A23 Vá 10 B22 8 12 

A25 8 1 B24 8 13 

Total de acertos | 68 108 66 132 


Para auxiliar a visualização e análise de dados, as Figuras 4.3 e 4.4 exibem os 
gráficos de acertos por participantes no pré e pós-teste, respectivamente. 
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Figura 4.3 — Gráfico de número de acertos por participantes no pré-teste(Aplicação 1). 


Número de acertos por participantes 
Pós-teste 


a meiii=s Grupo B 
[=] 
E mes Grupo A 
< 

4 

Del 

o] 1 


Participantes 


Figura 4.4 — Gráfico de número de acerto por participantes no pós-teste(Aplicação 1). 


As Figuras 4.3 e 4.4 comprovam as análises realizadas na Tabela 4.9. Portanto na 
primeira atividade de pré-teste, tivemos um equilíbrio entre os grupos. Na atividade de pós- 
teste o grupo experimental (Grupo B) foi nitidamente superior ao grupo de controle (Grupo 


A). 


4.4.2 Dados quanto ao tempo de resposta 
A tabela 4.10 exibe os dados quanto ao tempo de resposta no pré e pós-teste, ou 
seja, quantos minutos cada participante levou no preenchimento das lacunas do modelo i* 


e no preenchimento do formulário, em cada fase do experimento. 
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Tabela 4.10 — Tempo de resposta (em minutos) por participante para cada grupo (Aplicação 1). 


Participantes do Grupo de Controle Participantes do Grupo Experimental 

ld Participante | Pré-teste Pós-teste ld Participante | Pré-teste Pós-teste 
Ai 22 19 B2 12 5 

A3 34 26 B4 17 f 

As 20 nu B6 20 10 

A7 13 8 B9 34 32 

A8 32 30 B10 32 29 

Ai2 36 27 B13 23 18 

A16 35 25 B14 32 12 

Ai17 28 25 B15 24 15 

A19 22 17 B18 26 23 

AZ0 15 5 B21 1 2 

A23 31 14 B22 13 21 

A25 36 25 B24 20 9 


Tomando os dados na Tabela 4.10, ao compararmos a média gasto para o 
desenvolvimento de modelos i*, nas colunas de pré-teste e pós-teste dos dois grupos, 
o grupo experimental teve uma média menor no preenchimento das lacunas. Ou seja, O 
grupo experimental, obteve uma média de 22 minutos em relação ao grupo de controle, que 
obteve uma média de 27 minutos para o preenchimento das lacunas. O mesmo acontece 
no pós-teste, no qual o grupo experimental obteve uma média de 15 minutos para o 
preenchimento das lacunas no modelo. Ao contrário do grupo de controle que obteve uma 
média de 19 minutos para o preenchimento das lacunas no modelo. Isso demonstra que 
os participantes que utilizaram as diretrizes ontológicas, conseguem desenvolver modelos 
mais rápidos. Portanto é um indício a favor da nossa hipótese H2. 


4.4.3 Dados quanto ao número de acertos por questão 


As tabelas 4.11 e 4.12 exibem os dados resultantes das atividades para cada grupo, 
quanto ao número de acertos por questão na aplicação 1 do experimento, no pré e no 
pós-teste, respectivamente. Nossa intenção, com apresentação desses dados é verificar 
que questões foram mais difíceis, ou seja, obtiveram menor número de acertos. Para a 
análise de dados, consideramos questões difíceis aquelas em que menos da metade dos 
participantes acertaram. 
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Tabela 4.11 — Número de acertos por questão no Pré-teste (Aplicação 1) 


Pré-teste 
Questões Orientações do Wiki |* 
Grupo de Controle Grupo Experimental 
1 7 8 
2 6 7 
3 2 5 
4 9 8 
5 4 2 
6 6 Tá 
7 1 1 
8 4 3 
9 12 13 
10 5 8 
un 12 10 
Total de acertos 68 72 


Nota-se, pelos dados da Tabela 4.11 que, no pré-teste, para o grupo de controle, 


questões mais difíceis foram as de número 7, 3, 5, 8e 10 (nesta ordem). Já para o grupo 


experimental, as questões de número 7, 5, 8e 3 (nesta ordem) foram as questões mais 


difíceis. Nota-se que quatro dentre as cinco questões mais difíceis são as mesmas para 


ambos os grupos, ainda que com uma diferença na ordem. Listamos, a seguir, os conceitos/ 


links que os participantes deveriam saber diferenciar para cada uma das questões: 


* Questão 3: decomposição-OR e meio-fim-OR. 


* Questão 5: contribuição break, contribuição hurt e meio-fim. 


* Questão 7: contribuição break, contribuição hurt e meio-fim. 


- Questão 8: contribuição make, contribuição help e meio-fim. 


* Questão 10: contribuição make, contribuição help e meio-fim. 


Tabela 4.12 — Número de acertos por questão no Pós-teste (Aplicação 1) 


Questões 


Pós-teste 


Orientações do Wiki i* 


Diretrizes Ontológicas 


Grupo Controle 


Grupo Experimental 


1 12 8 

2 7 10 
3 1 1 
4 12 1 
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5 3 10 
6 11 12 
TA 10 ti 
8 4 3 
9 8 nu 
10 6 é 
1 5 10 
12 1 12 
13 4 nu 
14 3 8 
Total de acertos | 107 132 


A tabela 4.12 mostra que, no pós-teste, para o grupo de controle, as questões mais 
difíceis foram as questões de número 5, 14,8, 13 e 11 (nesta ordem). Já para o grupo 
experimental, as de número 8 e 10 foram as questões mais difíceis. Listamos, a seguir, 
os conceitos/links que os participantes deveriam saber diferenciar para cada uma das 
questões: 


* Questão 5: decomposição-OR e meio-fim-OR. 

*- Questão 8: contribuição make, contribuição help e meio-fim. 
* Questão 10: contribuição make, contribuição help e meio-fim. 
* Questão 11: contribuição break, contribuição help e meio-fim. 
* Questão 13: decomposição-OR e meio-fim-OR. 


* Questão 14: contribuição break, contribuição help e meio-fim. 


Pela comparação das questões mais difíceis do pré e do pós-teste, percebe-se que, 
para o grupo de controle, as mesmas dúvidas persistiram durante todo o experimento. 
Já o grupo experimental demonstrou, em geral, uma boa compreensão das diretrizes 
ontológicas, compreendendo bem o momento de empregá-las. Note pelas únicas duas 
questões difíceis para o grupo experimental no pós-teste que a única exceção se relaciona 
à distinção entre os links contribuição make, contribuição help e meio-fim. Isso demonstra 
que as diretrizes ontológicas referentes a esses links devem ser melhoradas para permitir 
uma diferenciação mais clara entre eles. 


4.4.4 Dados sobre a percepção quanto à utilidade das diretrizes ontológicas 


A Tabela 4.13, traz os dados referentes à percepção dos participantes em relação à 
utilidade do uso das orientações do Wiki i* e das diretrizes ontológicas. 
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Tabela 4.13 — Percepção dos participantes em relação à utilidade da Wiki i* e das diretrizes ontológicas 
(Aplicação 1). 


Respostas Orientações do Wiki /* (pré-teste) Diretrizes Ontológicas (pós-teste) 
Grupo Grupo de Controle | Grupo Experimental 
Experimental 

Muito útil 7 6 8 

Um pouco útil 5 5 2 

Indiferente 0 1 2 

Não muito útil 1 0 0 

Não é útil 0 0 0 


Como podemos observar na Tabela 4.13, 66,67% dos participantes avaliaram as 
diretrizes ontológicas como muito úteis na construção de modelos i*, enquanto 16,67% dos 
participantes informaram que as diretrizes ontológicas são um pouco úteis na construção 
de modelos i*, e 16,67% as consideraram indiferentes. 

A Tabela 4.14, mostra uma comparação das diretrizes ontológicas em relação às 
orientações do Wiki i*, realizada pelo grupo experimental. 


Tabela 4.14 — Diretrizes Ontológicas x Orientações do Wiki i* (Aplicação 1) 


Respostas Diretrizes Ontológicas x Orientações do Wiki i* 
Melhor Fá 
Mesma Qualidade 5 
Pior 0 


4.5. COLETA DE DADOS PARA A APLICAÇÃO 2 DO EXPERIMENTO 


Na aplicação 2, os participantes eram alunos do curso superior em Tecnologia em 
Análise e Desenvolvimento de Sistemas. No total de 30 participantes divididos em dois 
grupos de 15 participantes. Em relação ao tempo de experiência em modelagem de 
objetivos, os dois grupos encontravam equilibrados, já que nenhum dos participantes nos 
dois grupos tinha tempo de experiência em modelagem de objetivos e em >. 

Como objetivo de subsidiar a análise sobre aspectos importantes ligados ao resultado 
do experimento, optamos por apresentar os dados coletados em quatro subseções: 4.5.1 
concentra-se no número de acertos por participante, com o objetivo de fornecer subsídio 
para a análise da performance dos participantes dos dois grupos nas atividades propostas 
(buscando negar a hipótese HO e confirmar a hipótese H1); 4.5.2 focaliza o tempo de 
resposta dos participantes nas atividades no pré-teste e no pós-teste, para ajudar-nos a 
entender se o uso das diretrizes ontológicas leva a um retardo na escolha pelo elemento/link 
correto (procurando confirmar a hipótese H2); 4.5.3 apresenta dados relativos ao número 
de acertos por questão respondida, para permitir a análise das questões que trouxeram 
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maior grau de dificuldade para os participantes do experimento; 4.5.4 traz a avaliação da 
percepção dos participantes quanto a utilidade das diretrizes ontológicas e de como se 
comparam às orientações do Wiki i*. 


4.5.1 Dados quanto ao número de acertos por participantes 


Para viabilizar a comparação da performance dos participantes nas atividades do 
experimento com e sem o uso das diretrizes ontológicas, é importante analisar o número de 
acertos por participantes. A Tabela 4.15 mostra o número de acertos por participantes para 
cada grupo, nas atividades de pré-teste da aplicação 2 do experimento. 


Tabela 4.15 — Número de acertos por participantes para cada grupo (Aplicação 2). 


Participantes do Grupo de Controle Participantes do Grupo Experimental 
ld participante Pré-teste | Pós-teste | Id Participante Pré-teste Pós-teste 
AO1 2 4 BO2 3 a 
AO3 3 6 B04 3 6 
AOS 4 6 Bo6 4 6 
AO7 4 7 Bog 4 Tá 
AO8 4 7 B10o 5 9 
Ai2 6 8 B11 5 9 
A16 6 8 B13 EE] 10 
A17 6 8 B14 5 10 
A19 6 8 B15 7 10 
AZ0 Tá 9 B18 8 10 
A23 7 9 B21 8 10 
A25 8 9 B22 8 10 
A26 8 9 B24 9 12 
A28 8 10 B27 9 12 
A30 9 10 B29 10 13 
Total de acertos | 88 118 93 139 


Tomando os dados na Tabela 4.15, ao compararmos o total de acertos das colunas 
de pré-teste dos dois grupos, observamos que usando somente as orientações do Wiki i*, 
ambos os grupos ficaram equilibrados mesmo com uma diferença mínima de 3,33%. Já 
comparando o total de acertos da coluna de pós-teste, percebemos que, em porcentagem, 
o grupo experimental teve 73,33% de acertos em contraste a 26,67% obtido pelo grupo 
de controle. Portanto, o grupo experimental (Grupo B), grupo que utilizou as diretrizes 
ontológicas, foi nitidamente superior ao grupo de controle (Grupo A), que não teve acesso 
às diretrizes ontológicas. 
Para auxiliar a visualização e análise de dados, as Figuras 4.5 e 4.6 exibem os 
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gráficos de acertos por participantes no pré e pós-teste, respectivamente. 


Número de acertos por participantes 
Pré-teste 


= msi Grupo B 
[=] 
E mes Grupo A 
Eq 
0 
Participantes 
Figura 4.5 — Gráfico de número de acertos por participantes no pré-teste(Aplicação 2). 
Número de acertos por participantes 
Pós-teste 
w mis Grupo B 
=) 
5 mes Grupo À 
L 


Participantes 


Figura 4.6 — Gráfico de Acertos por participantes no pós-teste (Aplicação 2). 


As Figuras 4.5 e 4.6 comprovam as análises realizadas na Tabela 4.15. portanto 
na primeira atividade de pré-teste, tivemos um equilíbrio entre os grupos. Na atividade de 
pós-teste o grupo experimental (Grupo B) foi um pouco melhor ao grupo de controle (Grupo 


A). 
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4.5.2 Dados quanto ao tempo de resposta 


A Tabela 4.16. exibe os dados quanto ao tempo de resposta no pré e pós-teste, ou 
seja, quantos minutos cada participante levou no preenchimento das lacunas do modelo i* 


e no preenchimento do formulário, em cada fase do experimento. 


Tabela 4.16 — Tempo de resposta (em minutos) por participante para cada grupo (Aplicação 2) 


Participantes do Grupo de Controle Participante do Grupo Experimental 
ld Participante | Pré-teste Pós-teste | Id Participante Pré-teste Pós-teste 
Ai 31 30 B2 40 30 
A3 40 40 B4 40 30 
As 39 28 B6 38 40 
A7 40 22 B9 30 40 
A8 40 40 B10o 33 40 
Ai2 35 40 B11 30 25 
A16 33 40 B13 35 40 
A17 30 36 B14 34 38 
A19 31 27 B15 34 38 
AZ0 34 25 B18 32 26 
A23 40 29 B21 39 25 
A25 40 40 B22 40 34 
A26 40 40 B24 30 32 
A28 40 35 B27 40 28 
A30 40 28 B29 40 20 


Tomando os dados na Tabela 4.16, ao compararmos a média gasto para Oo 
desenvolvimento de modelos i*, nas colunas de pré-teste e pós-teste dos dois grupos, 
o grupo experimental teve uma média menor no preenchimento das lacunas. Ou seja, O 
grupo experimental, obteve uma média de 33 minutos em relação ao grupo de controle, que 
obteve uma média de 36 minutos para o preenchimento das lacunas no pré-teste. O mesmo 
acontece no pós-teste, mas com uma diferença mínima, no qual, o grupo experimental 
obteve uma média de 32 minutos para o preenchimento das lacunas no modelo. Ao 
contrário do grupo de controle que obteve uma média de 33 minutos para o preenchimento 
das lacunas no modelo. Isso demonstra que houve um equilíbrio entre os participantes 
que utilizaram as diretrizes ontológicas e os participantes que não utilizaram as diretrizes 
ontológicas. Portanto é um forte indício a rejeitar hipótese H2. 
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4.5.3 Dados quanto ao número de acertos por questão 


As Tabelas 4.17 e 4.18, exibem os dados resultantes das atividades para cada 
grupo, quanto ao número de acertos por questão na aplicação 2 do experimento, no pré e 
pós-teste, respectivamente. Nossa intenção, com a apresentação desses dados é verificar 
que questões foram mais difíceis, ou seja, obtiveram menor número de acertos. Para a 
análise de dados, consideramos questões difíceis aquelas em que menos da metade dos 
participantes acertaram. 


Tabela 4.17 — Número de acertos por questões no Pré-teste (Aplicação 2) 


Questões Pré-teste 
Orientações do Wiki /* 
Grupo de Controle Grupo Experimental 
1 10 8 
2 8 12 
3 4 5 
4 6 6 
5 2 2 
6 6 5 
7 1 3 
8 4 4 
9 12 8 
10 13 10 
1 10 8 
Total de Acertos | 76 71 


Nota-se, pelos dados da Tabela 4.17 que, no pré-teste, para o grupo de controle, 
questões mais difíceis foram as de números 7, 5, 3 e 8 (nesta ordem). Já para o grupo 
experimental, as questões de número 5, 7,8, 3e 6 (nesta ordem) foram as questões mais 
difíceis. Nota-se quatro dentre as cinco questões mais difíceis são as mesmas para ambos 
os grupos, ainda que com uma diferença na ordem. Listamos, a seguir, os conceitos/links 
que os participantes deveriam sabe diferenciar para cada uma das questões: 


* Questão 3: Decomposição-OR e meio-fim. 

* Questão 5: Contribuição-break, Contribuição-Hurt e meio-fim. 
* Questão 6: Contribuição-make, Contribuição-help e meio-fim. 
* Questão 7: Contribuição-break, Contribuição-hurt e meio-fim. 


* Questão 8: Contribuição-make, Contribuição-help e meio-fim. 
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Tabela 4.18 — Número de acertos por questões no Pós-teste (Aplicação 2) 


Questões Pós-teste 


Orientações do Wiki i* Diretrizes Ontológicas 


Grupo de Controle Grupo Experimental 
13 12 
10 13 
8 n 
12 10 


“q 
o 


= 
Er 
(9) 


ala! O/O|/NJNIO/A|L RIO) N]|a 


sa 
No 
Eq 
a 
EN 


= 
(oo) 


niIOjajla/a|EB/O|O|- 
(0.0) 


14 
Total de Acertos 115 139 


A Tabela 4.18 mostra que, no pós-teste, para o grupo de controle, as questões mais 
difíceis foram as questões de número 8, 9, 10, 11, 14 (nesta ordem). Já para o grupo 
experimental, a questão 14 foi a mais difícil. Listamos, a seguir, os conceitos/links que os 
participantes deveriam saber diferenciar para cada uma das questões: 


* Questão 8: Contribuição-make, meio-fim e Contribuição-help 
* Questão 9: Contribuição-break, meio-fim e Contribuição-help 
* Questão 10: Contribuição-make, meio-fim e Contribuição-help 
* Questão 11: Contribuição-break, meio-fim e Contribuição-help 


* Questão 14: Contribuição-break, meio-fim e Contribuição-help 


Pela comparação das questões mais difíceis do pré e do pós-teste, percebe-se que, 
para o grupo de controle, obteve-se mais dificuldades em relação ao grupo experimental. 
Demonstrando que o grupo experimental teve uma boa compreensão das diretrizes 
ontológicas, compreendendo bem o momento de empregá-las. Note-se que a única questão 
difícil para o grupo experimental se relaciona à distinção entre os links Contribuição-break, 
meio-fim e Contribuição-help. Isso demonstra que as diretrizes ontológicas referentes a 


esses links devem ser melhoradas para permitir uma diferenciação mais clara entre eles. 
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4.5.4 Dados sobre a percepção quanto à utilidade das diretrizes ontológicas 


A Tabela 4.19, traz os dados referentes à percepção dos participantes em relação à 
utilidade do uso das orientações do Wiki i* e das diretrizes ontológicas. 


Tabela 4.19 — Percepção dos participantes em relação à utilidade da Wiki i*e das diretrizes 
ontológicas (aplicação 2) 


Respostas Orientações do Wiki i* (pré-teste) Diretrizes Ontológicas (pós-teste) 
Grupo Experimental | Grupo de Controle Grupo Experimental 
Muito útil 6 4 10 
Um pouco útil | 7 8 3 
indiferente ps 2 2 
Não muito útil |1 0 0 
Não é útil 0 0 0 


Como podemos observar na Tabela 4.19, 66,67% dos participantes avaliaram as 
diretrizes 
ontológicas muito útil na construção de modelos i*. enquanto 20% dos participantes 
informaram que as diretrizes ontológicas são um pouco útil na construção de modelos i*, e 
13,33% consideraram indiferente. 
A Tabela 4.20, mostra uma comparação das diretrizes ontológicas em relação às 
orientações do Wiki i*, realizada pelo grupo experimental. 


Tabela 4.20 — Diretrizes Ontológicas x Orientações do Wiki i* (aplicação 2) 


Respostas Diretrizes Ontológicas x Orientações Wiki [* 
Melhor 13 

Mesma Qualidade 2 

Pior 0 


A Tabela 4.20 corrobora para a nossa análise, ou seja, 86,67% dos participantes 
informaram que as diretrizes ontológicas são melhores do que a Wiki i* no auxílio para 
construção de modelos i*. Entretanto, 13,33% dos participantes informaram que tem a 
mesma qualidade. 


4.6 — ANÁLISE DOS DADOS 


Esta seção é dedicada à análise descritiva dos dados coletados nas seções 4.4 e 4.5 
(subseção 4.6.1) e à apresentação dos resultados da aplicação de um método estatístico 
realizado para fazer comparações entre as médias das duas amostras independentes de 
cada aplicação do experimento, denominado teste de Wilcoxon-Mann-Whitney (Ferreira, 
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2009) (subseções 4.6.2 e 4.6.3). Em geral, apesar de fornecer bons indícios, a análise 
descritiva dos resultados não é suficiente para negar ou confirmar nenhuma hipótese. Daí 
a necessidade de realizar um método estatístico, que nos permite, assim, tirar conclusões 


mais seguras em relação aos resultados do experimento. 


4.6.1 Análise descritiva 


Na atividade de pré-teste realizada na aplicação 1, o grupo A obteve um número 
maior de acertos entre os participantes quando comparado ao grupo B. Já na atividade de 
pós-teste, o grupo B se sobressaiu sobre o grupo A, conforme pode ser visto nas tabelas 
4.9, 4.10 e 4.11 e nas Figuras 4.3 e 4.4. Assim, o Grupo B teve melhor desempenho 
utilizando as diretrizes ontológicas do que o grupo A que só teve acesso ao guia da Wiki |”. 
Esse resultado contradiz a hipótese HO e fortalece a nossa hipótese H1, resultado positivo 
para a nossa pesquisa. A avaliação sobre a utilidade das diretrizes ontológicas por parte 
dos participantes também fornece indícios favoráveis à nossa hipótese H1, já que na 
Tabela 4.13, 8 dos 12 participantes consideraram as diretrizes ontológicas muito úteis na 
construção de modelos i*, sendo que 2 as avaliaram como pouco úteis e os outros dois as 
acharam indiferentes. A Tabela 4.14 também fornece indícios favoráveis à nossa proposta, 
já que dos 12 participantes, 7 disseram que as diretrizes ontológicas tem melhor qualidade 
que as orientações do Wiki /*, 5 informaram que ambas tem a mesma qualidade e nenhum 
considerou as diretrizes ontológicas de pior qualidade. 

Na atividade de pré-teste realizada na aplicação 2, os grupos demonstraram um 
grande equilíbrio na realização das atividades, obtendo o mesmo número de acertos e erros. 
Já na atividade de pós-teste, o grupo experimental obteve um resultado melhor em relação 
ao grupo de controle, conforme pode ser visto nas tabelas 4.15, 4.16e 4.17 e as figuras 4.5 
e 4.6. Portanto, também nesse experimento o grupo experimental, ou seja, aquele que teve 
acesso às diretrizes ontológicas teve um melhor desempenho. Mais uma vez, a hipótese 
HO é negada e a hipótese H1, fortalecida. Quanto à percepção dos participantes quanto à 
utilidade das diretrizes ontológicas, os resultados da aplicação 2 também são favoráveis. A 
Tabela 4.19 também confirma a nossa hipótese H1, mostrando que 10 dos 15 participantes 
consideram as diretrizes ontológicas muito úteis para a construção de modelos i*, sendo 
que 3 as acharam pouco úteis e dois informaram que são indiferentes. A Tabela 4.20 
também corrobora com a nossa hipótese, já que 13 dos 15 participantes informaram que as 
diretrizes ontológicas são melhores que as orientações do Wiki i*, 2 acharam que ambas 
têm a mesma qualidade e nenhum considerou as diretrizes ontológicas de pior qualidade. 

Na atividade da aplicação 1, ficou claro que os participantes que utilizavam as 
diretrizes ontológicas, conseguiram preencher as lacunas dos modelos em menos tempo 
em relação aos participantes que não utilizavam as diretrizes ontológicas. Ou seja, os 
participantes do grupo experimental tiveram em média 15 minutos para a realização da 
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atividade, enquanto o grupo de controle teve em média 19 minutos. Na atividade de pós- 
teste o grupo experimental também foi melhor do que o grupo de controle. 

Na atividade da aplicação 2, houve um equilíbrio muito grande em relação aos 
participantes do grupo de controle e do grupo experimental. A diferença entre o grupo foi de 
um minuto, ou seja, o grupo de controle gastou em média 33 minutos para a realização da 
atividade e o grupo experimental gastou em média 32 minutos para o preenchimento das 
lacunas no modelo. A diferença entre os dois grupos, foi na atividade de pré-teste. Onde, o 
grupo de controle gastava 36 minutos, o grupo experimental gastou em média 33 minutos 
para a realização da atividade. 

Em resumo, os resultados de ambas as aplicações do experimento forneceram 
indícios para confirmar a hipótese de que as diretrizes ontológicas são úteis na criação 
de modelos i*. Esses resultados mostram, ainda, que as diretrizes ontológicas não exigem 
mais tempo do modelador que as orientações do Wiki i*. Para confirmar a validade desses 
indícios, a próxima seção apresenta o método estatístico realizado. 

Conforme mostra os dados das tabelas 4.11, 4.12, 4.17 e 4.18, podemos listar 
as questões que apresentaram mais dificuldades. Notamos, que em geral, no grupo de 
controle as dúvidas persistiram no pré e pós-teste. Já no grupo experimental mostrou-se 
que essas dúvidas foram sanadas e, para aquelas que não foram sanadas, sugerimos que 
as diretrizes ontológicas sejam melhoradas. 


4.6.2 Análise do teste estatístico quanto ao número de acertos 


O teste de Wilcoxon-Mann-Whitney é um método estatístico não-paramétrico 
recomendado para amostras pequenas, ou seja, grupos que tenham menos de 20 
participantes (Robson, 2002). Aplicamos o teste estatístico, com um nível de significância 
de 5%, para a comparação de acertos por participantes entre os grupos experimental e de 
controle, para ambas aplicações do experimento realizado. Como pode ser visto na Tabela 
4.21. 


Tabela 4.21 — Parte do framework, Parâmetro população e uso do teste estatístico. 


Parâmetros Justificativa 
populacionais 


[ ] Paramétrico A distribuição da população é igual e o experimento é realizado com mais 
de 20 participantes. 


[X] Não-Paramétrico | O objetivo do estudo é comparar o resultado do grupo experimento com o 
grupo controle, resultando em uma população não distribuídos igualmente. 
Além disso, o número de participantes é inferior a 20. 


Used Test Justificativa 


Mann-Whitney Este é um método não paramétrico estatístico. Além disso, de acordo 
com este ensaio, as amostras devem ser extraídos a partir da mesma 
população e as observações são comparáveis. 
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Para a Aplicação 1: 


Seguindo os procedimentos indicados pelo teste, primeiramente colocamos os 


valores (acertos) dos grupos experimental (B) e de controle (A) em ordem crescente (pós- 


teste, tabela 4.8), em uma nova tabela (Tabela 4.22). Em seguida, atribuímos valores, 


correspondentes às suas posições relativas na tabela (coluna Ordenação). Por exemplo, o 


primeiro elemento recebe o valor 1, o segundo elemento o valor 2 e assim sucessivamente. 


Por fim, se todos os valores de acerto forem seguidos um ao outro, sua classificação será 


idêntica à sua posição na coluna Ordenação (por exemplo, o valor 7 recebeu classificação 


1). Caso contrário, sua classificação será dada pelo cálculo da média de suas posições 


correspondentes (por exemplo, o valor 8 recebeu classificação igual a (2+6)/2=4) . 


Tabela 4.22 — Ordenação e classificação de acerto por participantes (Aplicação 1). 


Grupos | Acertos | Ordenação | Classificação 

A TA 1 1 

B 8 2 4 

B 8 3 4 

A 8 4 4 

A 8 5 4 

A 8 6 4 

A 9 7 8,5 
A 9 8 8,5 
A 9 9 8,5 
A 9 10 8,5 
B 10 u 12,5 
A 10 12 12,5 
A 10 13 12,5 
A 10 14 12,5 
B 1 15 16,5 
B 1 16 16,5 
B 1 LEA 16,5 
A 1 18 16,5 
B 12 19 21 
B 12 20 21 
B 12 21 21 
B 12 22 21 
B 12 23 21 
B 13 24 24 


O próximo passo é realizar o somatório dos valores da coluna Classificação dos 


elementos de cada grupo (A e B): 
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Somatório de Classificação do Grupo A = 101 
Somatório de Classificação do Grupo B = 199 


Em seguida, calculamos o valor de U para cada grupo, de acordo com a equação (1) 


e tomar o menor valor entre U e U,: 


NON,+1 
U=N, ni sá GR T onde 


Assim, temos que: 


U,=12x12+(12x(12+1))/2 -101=121 


U,=12x12+(12x(12+1))/ 2-199=23 
U=min (U,, U,) = min (121,23) = 23 


Por fim, comparamos o menor valor de U com o valor correspondente na tabela de 
teste de Mann-Whitney?. O valor crítico de U é o que se encontra na interseção entre a linha 
de índice N, e a coluna de índice N, na tabela de Mann-Whitney. Nesse caso, esse valor é 
37. Como o valor mínimo de U calculado é inferior ao valor crítico de U na tabela de Mann- 
Whitney, conclui-se que os valores são significativamente diferentes entre os grupos, o que 


aponta para a rejeição da hipótese nula (HO). 


Para a Aplicação 2: 


Os mesmos passos anteriores foram realizados para calcular o valor de U da 
aplicação 2 do experimento, iniciando-se, assim, com a determinação da ordenação e da 


1= número de participantes no grupo A 
»= número de participantesno grupo B (1) 


classificação do número de acertos por participantes, apresentados na tabela 4.28. 


Tabela 4.23 — Ordenação e classificação de acerto por participante (Aplicação 2) 


Grupos 


Acertos 


Ordenação 


Classificação 


1 


+alO/O|/NIOLA|EIOIN 


>D|i>D|I>P|DP|jWU|D|>|0|/W|m 


oC|O|NIN|NIO/O/O|/O0O|/0|/& 


— 
— 


2. http://math.usask.ca/-laverty/S245/TablesAymw.pdf 
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A 8 12 11,5 
A 8 13 11,5 
B 9 14 16,5 
B 9 15 16,5 
A 9 16 16,5 
A 9 17 16,5 
A 9 18 16,5 
A 9 19 16,5 
B 10 20 23,5 
B 10 21 23,5 
B 10 22 23,5 
B 10 23 23,5 
B 10 24 23,5 
B 10 25 23,5 
A 10 26 23,5 
A 10 27 23,5 
B 12 28 28,5 
B 12 29 28,5 
B 13 30 30 


A seguir, seguem os cálculos realizados quanto ao número de acertos para a 
aplicação 2: 

Somatório de Classificação do Grupo A = 185 

Somatório de Classificação do Grupo B = 280 

U,=15x15+(15x(15+1))/2 —185=160 

U,=15x15+(15x(15+1))/ 2-280 = 65 

U = min (160, 65) = 65 

O valor crítico de U na tabela de Mann-Whitney para N =15 e N,=15 é 64. Portanto, 
o valor mínimo de U encontrado é inferior ao valor crítico de U na tabela de Mann-Whitney, 
conclui-se que os valores não são significativamente diferentes entre os grupos, o que é 


favorável a hipótese nula HO. 


Análise final dos resultados quanto ao número de acertos 


Enquanto o método estatístico Mann-Whitney confirmou a hipótese H1 para 
a primeira explicação do experimento, esse mesmo teste negou a hipótese H1 para a 
aplicação 2. Buscando entender as possíveis causas dessa diferença de resultado, 
olhamos para o perfil dos participantes. Um fator que corrobora com essa diferença é o 
grau de instrução dos participantes. Na aplicação 1, os participantes eram compostos por 
alunos de graduação em Ciência da Computação, Engenharia da Computação, Mestrado 
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em Informática e Doutorado em Ciência da Computação, diferentemente da aplicação 2, 
na qual os participantes eram todos alunos de graduação em Tecnólogo em Análise e 
Desenvolvimento de Sistemas. Isso nos leva a crer que os participantes da aplicação 1 são, 
em geral, mais experientes em modelagem conceitual que os da aplicação 2. 

Examinando o número de pessoas que indicaram ter experiência com o uso de 
i* na aplicação 1, havia três pessoas, comparado a nenhuma na aplicação 2. Ainda que 
o número seja superior na aplicação 1, não podemos dizer que a experiência com i* em 
particular tenha gerado uma diferença, já que se tratam de três pessoas em um total de 
vinte e quatro participantes. 

Concluímos, portanto, que as diretrizes ontológicas são úteis para modeladores mais 
experientes e com maior grau de instrução. Por outro lado, percebemos que a diferença 
no valor esperado para o teste de Mann-Whitney na aplicação 2 foi mínima, de apenas 
dois pontos (U crítico deveria ser maior que 65), o que nos fornece indícios positivos. A 
realização de novos experimentos, com participantes de diferentes perfis é, nesse caso, 
indicada para que se possam obter novas conclusões. 


4.6.3 Análise do Teste Estatístico quanto ao Tempo de Resposta 


Também foi realizada uma análise em relação ao tempo de resposta para os 
preenchimentos das lacunas no modelo i*, novamente usando o teste de Mann-Whitney. 


Para a Aplicação 1: 


A Tabela 4.24 mostra os dados já ordenados e classificados da atividade (pós-teste) 
realizada na aplicação 1 dos grupos de controle e experimental. 


Tabela 4.24 — Tempo de resposta (Aplicação 1) 


Grupos | Tempo gasto Ordenação | Classificação 
B 2 1 1 

B 5 2 2,5 
A 5 3 2,5 
B 7 4 4 
A 8 5 5 

B 9 6 6 

B 10 7 Vá 
A 1 8 8 

B 12 9 9 
A 14 10 10 
B 15 un nu 
A 17 12 12 
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B 18 13 13 
A 19 14 14 
B 21 15 15 
B 23 16 16 
A 25 17 18 
A 25 18 18 
A 25 19 18 
A 26 20 20 
A 27 21 21 
B 29 22 22 
A 30 23 23 
B 32 24 24 


A seguir, seguem os cálculos realizados quanto ao tempo de resposta para a 
aplicação 1: 

Somatório de Classificação do Grupo A = 169,5 

Somatório de Classificação do Grupo B = 130,5 

U,=12x12+(12x(12+1))/2 —169,5=52,5 

U,=12x12+(12x(12+1))/ 2-130,5=91,5 

U = min (52.5, 91.5) = 52,5 

O valor de U encontrado entre o mínimo de U e U, é 52.5, e o valor crítico de 
U na tabela de Mann-Whitney é 37 para N=12 e N=12. Como o valor mínimo de U é 
superior ao valor crítico de U na tabela de Mann-Whitney, conclui-se que os valores não 
são significativamente diferentes, o que rejeita a hipótese H2. 


Para a Aplicação 2: 


A Tabela 4.25 mostra os dados já ordenados e classificados da atividade (Pós-teste) 
dos grupos de controle e experimental. 


Tabela 4.25 — Tempo de resposta (Aplicação 2) 


Grupos | Tempo gasto | Ordenação | Classificação 
B 20 1 1 
A 22 2 2 
B 25 3 4 
B 25 4 4 
A 25 5 4 
B 26 6 6 
A 27 7 7 
B 28 8 9 
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A 28 9 

A 28 10 

A 29 1 1 

B 30 12 13 
B 30 13 13 
A 30 14 13 
B 32 15 15 
B 34 16 16 
A 35 17 17 
A 36 18 18 
B 38 19 19,5 
B 38 20 19,5 
B 40 21 25,5 
B 40 22 25,5 
B 40 23 25,5 
B 40 24 25,5 
A 40 25 25,5 
A 40 26 25,5 
A 40 27 25,5 
A 40 28 25,5 
A 40 29 25,5 
A 40 30 25,5 


A seguir, seguem os cálculos realizados quanto ao tempo de resposta para a 
aplicação 2: 

Somatório de Classificação do Grupo A = 243 

Somatório de Classificação do Grupo B = 222 

U,=15x15+(15x(15+1))/2 —-243=102 

U,=15x15+(15x(15+1))/ 2-222=123 

U = min (102, 123) = 102 

O valor de U encontrado entre o mínimo de U, e U, é 102, e o valor crítico de U na 
tabela de Mann-Whitney é 64 para N1=15 e N2=15. Como o valor mínimo encontrado de U 
é superior ao valor crítico de U na tabela de Mann-Whitney, conclui-se que os valores não 
são significativamente diferentes, o que, portanto, rejeita a hipótese H2. 


Análise final dos resultados para o tempo de resposta 


Considerando, que os resultados das aplicações 1 e 2 para a análise do tempo de 
resposta no preenchimento das lacunas da atividade pós-teste não foram significativamente 
diferentes segundo o método do teste estatístico de Mann-Whitney. Portanto, ambas as 
aplicações tiveram resultados desfavoráveis à hipótese h2. Conclui-se que as diretrizes 
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ontológicas não ajudam a desenvolver modelos i* mais rápidos. 
O framework utilizado para a realização do experimento encontra-se completo nos 
apêndices A e B respectivamente. 


4.7 - CONSIDERAÇÕES FINAS DO CAPÍTULO 


O estudo empírico é uma forma eficiente de provar a eficácia de uma nova abordagem 
ou pesquisa realizada. O experimento é um tipo de estudo empírico que identifica a relação 
de causa e efeito. Portanto, é uma atividade que permite manipular variáveis e observar 
outras, com o propósito de realizar a medição de um fenômeno de interesse (Sjoberg et 
al., 2005). 

Neste capítulo, foi apresentado o experimento realizado com o objetivo de validar as 
diretrizes ontológicas, descritas no capítulo 3. 

Em primeiro lugar, o capítulo trouxe informações sobre o framework em que o 
experimento se baseou. Esse framework é dividido em duas partes, a primeira parte, trata 
dos momentos de definição e planejamento do experimento, detalhando os procedimentos 
que serão realizados no momento que o experimento for aplicado. A segunda parte trata 
dos elementos a serem observados no momento da análise e interpretação dos dados. 

A aplicação do experimento se deu em duas etapas, pré-teste e pós-teste e os 
dados foram coletados em formulários contendo informações sobre o perfil do participante, 
informações das atividades de modelagem realizadas e a percepção dos participantes em 
relação da utilização das diretrizes ontológicas. 

Além da análise descritiva dos resultados, foi utilizado o teste de Wilcoxon-Mann- 
Whitney, um método estatístico não paramétrico recomendado para amostras pequenas, 
recomendados para experimentos contendo grupos inferiores a 20 participantes (Robson, 
2002). Foram realizadas análises para número de acertos por participante, para o tempo 
de resposta dos participantes nas atividades do experimento e para o número de acertos 
por questão. 

A rejeição da hipótese HO no experimento realizado na aplicação 1 comprova 
que as diretrizes ontológicas são úteis na criação de modelos i*. Entretanto, o mesmo 
não ocorre no experimento realizado na aplicação 2. A diferença no resultado se deve à 
divergência nos perfis dos participantes dos experimentos, principalmente quanto ao grau 
de instrução. Concluímos que o uso das diretrizes ontológicas é eficaz para modeladores 
mais experientes. Entretanto, o resultado de Mann-Whitney para a aplicação 2 foi bem 
próxima ao esperado, assim, novos experimentos são indicados para verificar se não seria 
possível generalizar essa afirmação para modeladores em geral. 

Ambas as aplicações rejeitam a hipótese H2, ou seja, as diretrizes ontológicas 
não mostram eficiência em auxiliar os desenvolvedores a criarem modelos i* em menos 
tempos. Portanto, as diretrizes ontológicas não se mostram eficazes no desenvolvimento 
de modelos mais rápidos. 
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CAPÍTULO 5 


EM BUSCA DE APOIO AUTOMATIZADO COM BASE NAS 
DIRETRIZES ONTOLÓGICAS 


Este capítulo tem o objetivo de propor formas de suporte automatizado utilizando as diretrizes 
ontológicas descritas no capítulo 3 e validadas por meio do experimento do capítulo 4. Para 
isso, apresenta um metamodelo de i*, desenvolvido compatível com as diretrizes ontológicas 
e um propõe a criação de um plugin para construção de modelos baseado em um diálogo 
com o modelador. A partir do metamodelo e do plugin propostos, é possível desenvolver uma 
ferramenta de modelagem de i* que dê suporte ao modelador, guiando-o de acordo com as 
diretrizes ontológicas. O capítulo está organizado da seguinte maneira: a seção 5.1 introduz 
o capítulo; a seção 5.2 apresenta teoria sobre metamodelagem; a seção 5.3 descreve o 
metamodelo adotado aqui como base para o desenvolvimento do novo metamodelo; a seção 
5.4 propõe um metamodelo compatível com as diretrizes ontológicas; a seção 5.5. propõe o 
plugin de modelagem i* dialogada; a seção 5.6 apresenta o trabalho relacionado; e por fim, a 
seção 5.7 traz as considerações finais do capítulo. 


5.1 - INTRODUÇÃO 


Com o surgimento de múltiplos dialetos, surgem também diversas ferramentas 
para desenvolvimento de modelos /*. Dentre delas, podemos citar a ferramenta OpenOME 
(Open Organizational Modeling Environment), que desenvolve modelos de propósito geral 
para modelagem e análise orientada a objetivos, com base em i* original. Outra ferramenta 
bastante utilizada é JUCMNav, dedicada à criação de modelos GRL. E por fim, citamos, a 
ferramenta TAOM4E (Tool for Agent-Oriented visual Modeling for the Eclipse Platform), que 
foi desenvolvida para criar modelos orientados a agentes seguindo a metodologia Tropos 
(Santos, 2008). Várias outras ferramentas, criadas com base nos diversos dialetos de i* 
estão disponíveis para download no Wiki |”. Como já mencionado em Santos (2008), o uso 
de diferentes ferramentas produz modelos divergentes e até mesmo conflitantes acerca do 
sistema modelado. 

Como visto no capítulo 4, em geral, os participantes dos experimentos realizados 
tiveram uma boa aceitação quanto ao uso das diretrizes ontológicas para dar apoio à 
criação de modelos i*. Resta saber, então, como tais diretrizes podem estar embutidas em 
ferramentas de modelagem i*, fornecendo, assim, apoio prático à modelagem conceitual. 

O uso de metamodelos vem se popularizando como uma boa prática no 
desenvolvimento de sistemas, seguindo o paradigma do desenvolvimento orientado a 
modelos. Tal paradigma dita que, com o objetivo de gerar softwares mais confiáveis e 
de mais fácil manutenção, desde especificações abstratas até o código de um programa 
devem ser baseados em modelos, que vão se transformando sistematicamente uns nos 


1. Mais especificamente, essas ferramentas são encontradas em http:/istar.rwth-aachen.de/tiki-index.php?page=i"+- 
Tools 
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outros, mantendo-se, assim, uma rastreabilidade entre os modelos mais abstratos e os mais 
concretos?. No centro diversas transformações, se encontram metamodelos, que definem a 
sintaxe abstrata da linguagem em que os modelos se baseiam. Um metamodelo é, portanto, 
um diagrama composto de conceitos e relações, explicitando, assim, os construtos da 
linguagem. Além disso, esses construtos são relacionados de uma determinada maneira, 
o que define regras de formação dos modelos escritos com determinada linguagem. Para 
dar exemplo de uma linguagem padrão, o metamodelo da UML especifica conceitos sobre 
classes, objetos, métodos, associações entre outros (Vale, 2011). Já nos metamodelos de 
i*, é possível identificar regras entre os elementos intencionais e links, portanto, conceitos 
como agente, objetivo, meio-fim e decomposição devem ser encontrados (Amyot et al., 
2009), (Susi et al., 2005),(Lucena et al., 2008). 

Algumas ferramentas de modelagem de i* se baseiam no uso de metamodelos. 
Por exemplo, o TAOM4E possui um metamodelo divido em três partes: core, diagram e 
project (Bertolini; Suse; Perini, 2006). Core representa os conceitos e relações referentes 
ao modelo de negócio, que contém o esquema de dados, definindo pacotes e classes; 
diagram representa a visão do modelo, onde estão todas as informações gráficas; e project 
se refere ao gerenciamento das produções de diferentes artefatos criados pelas atividades 
de modelagem. A ferramenta JUCMNav, por sua vez, possui dois metamodelos, um para 
representar o nível abstrato e outro para representar a forma da implementação. 

Nesse capítulo, propomos um metamodelo compatível com essas diretrizes, com 
base em um metamodelo existente, definido para a linguagem istarML (Cares; Franch, 
2011). Dentre os metamodelos de i* existentes, este foi selecionado, por ter sido 
implementado com base na análise de diversos metamodelos existentes e com vistas a 
prover interoperabilidade entre modelos i*. O metamodelo proposto neste capítulo poderá, 
no futuro, servir de base para o desenvolvimento de uma ferramenta que dê suporte para o 
desenvolvimento de modelos i* seguindo as diretrizes ontológicas. 

Como mencionado no capítulo 1 desta dissertação, o metamodelo não é, entretanto, 
um método eficiente para especificar a semântica de uma linguagem de modelagem. 
Algumas regras de interconectividade entre conceitos podem ser capturadas, mas não 
todas. Muitas questões semânticas surgem e devem ser analisadas de acordo com o 
contexto de modelagem, no momento em que o modelador está criando os modelos de seu 
sistema. É nesse momento que muitas das diretrizes ontológicas serão úteis. Para prover 
apoio ao modelador, este capítulo propõe, assim, a criação de uma espécie de plugin, 
que conduza o modelador em um diálogo e, pouco a pouco, leve à criação do modelo. 
Chamamos esse plugin de modelagem i* dialogada e nos inspiramos em um trabalho 
anterior de criação de ontologias (Guizzardi; Graças; Guizzardi, 2011). Combinando, assim, 
o uso de um metamodelo e este plugin, ambos com base nas diretrizes ontológicas, espera- 
se levar a modelos de maior qualidade. 


2. http:/Aww.omg.org/cgi-bin/doc?ormsc/1 0-09-06.pdf 
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5.2 - METAMODELAGEM 


Para Fernandes Neto (2012), um metamodelo define os construtores de uma 
linguagem de modelagem e seus relacionamentos, bem como as constantes e regras 
de modelagem. Cares (2012) descreve que um metamodelo é uma ferramenta utilizada 
para representar modelos válidos. Portanto, é uma ferramenta que tem como objetivo 
representar modelos válidos de uma determinada linguagem de modelagem. Em outras 
palavras, o metamodelo define a sintaxe abstrata de uma linguagem de modelagem. 

De acordo com Cares (2012), a linguagem usada para representar um metamodelo 
é chamada de metalinguagem. Em outras palavras, para determinar um metamodelo, é 
necessário ter uma linguagem de metamodelação, que por sua vez é descrita através de um 
metametamodelo. Um exemplo de linguagem de metamodelação é o padrão Meta-Object 
Facility? (MOF)). A Figura 5.1 representa os níveis envolvidos no uso de um metamodelo. 


Tipo: Classifier 


M3: Metametamodelo ro sed 


<< Instance of a | |<< Describes >> 


Tipo: Classifier 
À Nome: Classifier 
M2: Metamodelo Propriedades: atributos, 


operações e assossiações 


<< Instance of a | | Describes >> 
Tipo: Class 
, Nome: Pessoa 
M1: Modelo Propriedades: nome e 
idade 
<< Instance of a | | Describes >> 


Tipo: Pessoa 
MO: Instância ou Objeto Nome: José 
Idade: 23 


Figura 5.1 — Representação dos níveis de Metametamodelo. Fonte (Dias, 2008) 


A Figura 5.1 representa o metamodelo em quatro níveis (Lucredio, 2009): (i) MO 
- Instância ou objeto são as instâncias dos modelos, ou seja, representam os dados 
propriamente ditos; (ii) M1 - Modelo deve estar em conformidade com M2 e contém os 
conceitos e relações que modelam MO. Em outras palavras, corresponde aos metadados, ou 
seja, os dados que descrevem os dados; (iii) M2 - Metamodelo, deve estar em conformidade 
com M3 e define a sintaxe abstrata (construtos) da linguagem usada para modelar o modelo 
M1 (iv) M3 - Metametamodelo, que determina a sintaxe abstrata (construtos) da linguagem 
usada para definir o metamodelo de M2. 


3. MOF é um padrão orientado a objeto que possibilita a definição de classes, atributos e relacionamentos, parecido 
com diagrama de classes da Linguagem de Modelagem Unificada (UML). 
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No desenvolvimento orientado a Modelos, a metamodelação é o método utilizado 
para a definição de linguagens específicas do domínio (DSL), que pode ser usada no nível 
M1 descrito acima. A metamodelagem facilita a geração automática de código, pela criação 
de um template que se refere ao metamodelo da DSL. 

Uma grande vantagem do metamodelo é a autonomia com metodologias de 
desenvolvimento e plataformas de implementação, possibilitando utilizar o código fonte para 
diversas plataformas. Além disso, ele pode facilitar a interoperabilidade entre modelos. Por 
exemplo, no contexto de i*, é possível obter os metamodelos dos principais dialetos de i*, 
possibilitando o entendimento das diferenças entre esses dialetos. A partir daí, é possível 
definir mapeamentos entre os diversos dialetos, como proposto em (Cares; Franch, 2011) 
e (Cares, 2012). 


5.3 - METAMODELO ISTARML 


Cares (2012) propõe um framework formal para dar suporte a modelos de 
interoperabilidade, tendo como objetivo prover uma estrutura para compreender as 
variações entre os diversos dialetos de i* e dar suporte à interoperabilidade e integração 
dessas variações. Para isso, o trabalho faz uma revisão da literatura realizada em 2007 e 
atualizada em 2008, resumindo as variações existentes e trazendo uma análise detalhada 
da relação do i* com as ferramentas existentes hoje na comunidade |*. 

Cares (2012) utiliza o trabalho de (Ayala et al., 2005) para chegar a um metamodelo 
de referência para i*. Além disso, o trabalho define um núcleo conceitual estável de i*, ou 
seja, conceitos e relações comuns entre os diversos dialetos, propondo um metamodelo. 
Com base nesse metamodelo, Cares (2012) desenvolveu um modelo de intercâmbio 
baseado em XML* denominado iStarML. iStarML, tem como propósito interoperar um 
conjunto de dialetos de i*. 

Como podemos observar na Figura 5.2, Cares (2012) dividiu o metamodelo em seis 
áreas distintas: (i) área 1 (ator) — representa unidades organizacionais, seres humanos 
ou agentes de software; (ii) área 2 (elementos intencionais) — representa um conjunto 
de elementos usados na modelagem de intenções do ator; (iii) área 3 (dependência) — 
representa as dependências entre os atores; (iv) área 4 (limites) — representa o limite 
que define a perspectiva dos atores; (v) área 5 (ligações entre elementos intencionais) 
— representa as relações entre os elementos intencionais; por último, (vi) área 6 (ligação 
associação entre atores) — representa as relações entre os atores como is part ofeis a, 


entre outros. 


4. XML É uma linguagem recomendada pela World Wide Web Consortium (W3C) para criar linguagens de marcação 
para necessidades especiais. 
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<<enumeration>> 
IntentionalType 


Goal 


label: String 


As 


<«<enumeration=> 
ContributionType 


+ 


Softgoal 
Resource 
Task 


(complete) 


dependee 


(disjoint, 
complete) 


IntentionalElement 
type: IntentionalType 


* + 


- type : IntentionalType 


(disjoint, complete) 


head 


Figura 5.2 - Os conceitos do núcleo i* no contexto do i* metamodelo. - Fonte (Cares, 2012). 


5.4 - METAMODELO COMPATÍVEL COM AS DIRETRIZES ONTOLÓGICAS 


Esta seção apresenta o metamodelo que tem como objetivo ser uma referência para 
a modelagem i*, com base nas diretrizes ontológicas apresentadas no capítulo 3. Este 
metamodelo foi feito com base no metamodelo apresentado na seção anterior. Buscando 
compatibilidade com as diretrizes ontológicas, o metamodelo anterior foi modificado: a) 
adicionando classes; b) excluindo classes e relacionamentos; b) definindo restrições no 
uso das classes e relacionamentos existentes. 


A Figura 5.3 apresenta o metamodelo resultante. 
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<<<<enumerati on>>>> 
ContributionType 


<<<<enumerati on>>>> 
Means-EndType 
+0r 


+And 
EI 


<<<<enumerati on>>>> 
DecompositionType 
+0r 
+And 
E TTÃ 


<<<<enumerati on>>>> 
IntentionalType 
+Goal 
+SoftGoal 
+Fesource <> 
1 
, 
1 


+Task 
| 


Dependency 
+-/Type: IntentionalType 


IntentionalElement 
+Type: IntentionalType 
ES 

7 


tdisjoint, complete) 


[Actor | SE —esunda A InternalElement 
ET um E 
1º (Subset) 
0.1 rootOf 


Decomposition 
+Type: DecompositionType 


(disjoint, incomplete 


Contribution 
+Type: ContributionType 
EA 


[+Iype: Means- EndT ype 


Figura 5.3 — Metamodelo i* Diretrizes Ontológicas. 


A seguir, listamos as alterações que foram feitas em relação ao metamodelo proposto 
por (Cares, 2012): 


Acrescentamos novas classes Enumeration: 


* Enumeration DecompositionType, que tem como atributos Or e And, com o 
objetivo de definir tipo de decomposição a ser utilizado. 


* Enumeration Means-EndType, que tem como atributos Or e And, com o ob- 
jetivo definir o tipo de link meio-fim. 


* | Enumeration ContributionType, tem como atributos Help, Hurt, Make e 
Break, com o objetivo de definir o tipo de link de contribuição 


Retiramos as classes Agent e Position, mantendo apenas Actor e Role. On- 
tologicamente, o que importa é se o conceito é rígido ou antirígido, ou seja, 
se uma entidade daquele tipo é sempre uma entidade daquele tipo ou se ela 
pode mudar de tipo. Por exemplo, enquanto uma pessoa é um ator (Actor), um 
estudante ou uma vendedora são papeis (Role). Essa diretriz ontológica não foi 
descrita no capítulo 3 porque não foi incluída no experimento apresentado no 
capítulo 4, para que as atividades experimentais não ficassem muito comple- 
xas. O mesmo pode ser dito para as diretrizes relacionadas com o conceito de 
Dependency. Para mais informações sobre essas diretrizes, referimos o leitor 
para (Guizzardi; Guizzardi, 2010). 


Acrescentamos atributos novos nas classes Decomposition, Means-End e Con- 
tribution. Os atributos são: DecompositionType, Means-endType e Contribu- 
tionType respectivamente. Esses atributos se referem às classes Enumeration 
DecompositionType, Enumeration Means-EndType e Enumeration Contribu- 
tionType, respectivamente. 
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As seguintes restrições se aplicam ao metamodelo da figura 5.8. 


* | Decomposition só pode ser utilizada entre elementos do mesmo tipo, ou seja: 


* | Intentional Element (Type: Softgoal) e Intentional Element (Type: Softgoal) 
* | Intentional Element (Type: Goal) e Intentional Element (Type: Goal) 


* | Intentional Element (Type: Task) e Intentional Element (Type: Task). 
* | Means-end só pode ser utilizada entre elementos de tipos distintos: 


* | Intentional Element (Type: Task) e Intentional Element (Type: Softgoal) 


* | Intentional Element (Type: Resource) e Intentional Element (Type: Softgoal) 


( 

( 
* | Intentional Element (Type: Task) e Intentional Element (Type: Goal) 
* -Intentional Element (Type: Resource) e Intentional Element (Type: Goal) 
( 


* | Intentional Element (Type: Resource) e Intentional Element (Type: Task). 


5.5 - PLUGIN PARA MODELAGEM I* DIALOGADA 


Esta seção apresenta um plugin para orientar os modeladores na construção de 
modelos i*. Esse plugin se caracteriza por manter um diálogo com o modelador, conduzindo-o 
passo a passo à construção de modelos i*, orientando-o conforme as diretrizes ontológicas. 
Esse plugin tem como propósito ser utilizado pela ferramenta de desenvolvimento eclipse. 
A nossa ideia foi o desenvolvimento de um protótipo, pela razão de não ter tempo suficiente 
para o desenvolvimento, ficando assim para trabalhos futuros. 

Vamos supor o modelo da Figura 3.8 do capítulo 3, que tem como ator o “Planejador 
de Conferência”, cujo objetivo principal é “não gastar dinheiro com o palestrante”. Segue na 
tabela 5.1 a representação de como o plugin irá auxiliar o modelador no desenvolvimento 
do modelo. A legenda os passos descritos na tabela são representados também na Figura 
5.4. 
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Tabela 5.1 - Representação de um diálogo entre plugin e modelador 


Legenda: 


e, :Modelador modifica modelo; 7 Plugin pergunta; & Modelador responde; e. Plugin 
modifica modelo; O Plugin faz sugestão. 


1 AR 
e, Insere Ator “Planejador de conferência” 

2 A entidade que é “Planejador de conferência” é sempre deste tipo até o 
? fim da modelagem” Se ela pode ser também de um outro tipo durante a 

modelagem, responda Não? 

3 O) Sim 

5 ' e sda aa » 
à M Insere Elemento Genérico “Não gastar dinheiro com palestrante 

6 2 “Não gastar dinheiro com palestrante” é uma tarefa ou uma sequência de 
E tarefas? 
[G) Não 
2 “Não gastar dinheiro com palestrante” é um objetivo, ou seja, reflete uma 


intenção do ator em relação a uma situação que ele almeja obter? 


9 O) Sim 


10 E 
e. Troca o tipo do Elemento Genérico para Objetivo 
1 Neste momento, você pode decompor o objetivo em subobjetivos 
o (Decomposição-AND), analisar objetivos alternativos (Decomposição-OR) 


ou então inserir tarefas ou recursos que sejam meios para atingir o objetivo 
modelado (Meio-fim). 


12 q 
e, Insere a tarefa “Obter patrocínio para palestrante” 
w 
13 e Insere o link decomposição-OR ligando a tarefa “Obter patrocínio para 
M palestrante” e o objetivo “Não gastar dinheiro com palestrante” 
14 Um objetivo só pode ser decomposto em sub-objetivos. Tem certeza de 
(O) que “Obter patrocínio para palestrante” é uma tarefa? Em caso afirmativo, 
use um link meio-fim. 
15 à pi E e 
à M Troca o tipo da tarefa “Obter patrocínio para palestrante” para objetivo 
16 e Insere automaticamente um outro subobjetivo ligado por decomposição-OR 
P ao objetivo “Não gastar dinheiro com palestrante” 
17 p E : ” 
, M Insere a tarefa “Convidar palestrante patrocinado 
18 e Insere o link meio-fim ligando a tarefa “Convidar palestrante patrocinado” e 
M o objetivo “Obter patrocínio para palestrante” 
19 Neste momento, você pode decompor a tarefa em subtarefas 
o (Decomposição-AND), analisar tarefas alternativas (Decomposição-OR) ou 
então inserir recursos que sejam meios para atingir o objetivo modelado 
(Meio-fim). 


Em busca de apoio automatizado com base nas diretrizes ontológicas 


78 


20 


e, Insere o link decomposição-AND 


21 


e Insere automaticamente duas subtarefas ligadas por decomposição-AND à 
ww p tarefa “Convidar palestrante patrocinado” 


22 


e Troca o nome das subtarefas inseridas para “Obter patrocínio com 
M parceiros” e “Convidar palestrante profissional” 


23 


e, Modelador tenta fechar a janela, dando o modelo como finalizado 


24 


O seu modelo tem uma decomposição-OR com apenas um subobjetivo. 
Note que para analisar alternativas, são necessários pelo menos dois 
subobjetivos. (esta mensagem aparece porque o modelador não colocou o 
nome do objetivo inserido automaticamente pelo plugin - linha 16) 


25 


e, Troca o nome do objetivo inserido para “Convidar um palestrante gratuito” 


26 


e Insere link Contribuição Genérica entre tarefa “Convidar palestrante 
M profissional” e o objetivo “Convidar um palestrante gratuito” 


27 


Que tipo de Contribuição é esta? 

Se a tarefa “Convidar palestrante profissional” leva a uma situação que 
nega completamente o objetivo “Convidar um palestrante gratuito”, 
responda B. 

Se a tarefa “Convidar palestrante profissional” leva a uma situação que 
nega parcialmente o objetivo “Convidar um palestrante gratuito”, responda 
2 HU. 

Se a tarefa “Convidar palestrante profissional” leva a uma situação que 
atinge parcialmente o objetivo “Convidar um palestrante gratuito”, responda 
HE. 

Se a tarefa “Convidar palestrante profissional” leva a uma situação que 
atinge completamente o objetivo “Convidar um palestrante gratuito”, 
responda M. 


28 


[G) B 


29 


Troca o link Contribuição Genérica para Contribuição break e insere 
e automaticamente um link Contribuição hurt entre o a tarefa “Convidar um 
P palestrante profissional” e o objetivo “Não gastar dinheiro com palestrante” 


* | Seguem observações sobre o modo de diálogo adotado pelo plugin: 


* Para que o diálogo não se torne repetitivo, apenas nas primeiras ocorrên- 
cias dos elementos intencionais, o plugin pergunta sobre seus tipos. Como 
logo nas linhas 5 a 10, levantou-se a diferença entre tarefa e objetivo, o 
plugin não pergunta mais sobre isso. 


* Se o modelador tivesse respondido não na linha 3, o plugin teria modificado 
o tipo do ator para papel. 


* Sempre que aparece um novo elemento intencional no modelo pela primeira 
vez, o plugin faz algumas sugestões de modelagem, como nas linhas 11 e 
19. 
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* Várias possibilidades de modelagem são possíveis e a ideia é que o plugin 
adapte o diálogo a elas. Por exemplo, na linha 12, o modelador inseriu um 
elemento intencional (tarefa) e depois se preocupou com a forma de liga- 
ção entre ele e o restante do modelo; já na linha 20, o modelador parte da 
escolha do link decomposição-AND e o plugin se adapta, automaticamente 
inserindo duas tarefas no modelo. 


* Outra variação de modelagem que caracterizamos é que ao inserir a de- 
composição-OR (linha 13), o modelador seguiu modelando apenas um ga- 
lho da árvore de objetivos e o plugin precisou lembrá-lo, na linha 24, que 
ele precisava modelar o outro galho. Já na linha 22, o modelador decidiu 
modelar ambos os galhos da árvore de tarefas. 


Mesmo que tenhamos tido a preocupação de sermos os menos intrusivos pos- 
síveis, temos a consciência de que o plugin é um recurso mais apropriado para 
modeladores iniciantes e que, com o tempo, o modelador não precisará mais do 
auxílio do diálogo. Uma alternativa menos intrusiva seria deixar que o modela- 
dor desenvolva todo o modelo e, depois, ter uma ferramenta de checagem que 
faça a varredura do modelo e exiba, para o modelador, mensagens (warnings) 
quanto a não compatibilidade com as diretrizes ontológicas, deixando a seu 
critério obedecê-las ou não. Uma ferramenta poderia, inclusive, fornecer essas 
duas ferramentas, o plugin e o verificador, deixando a cargo do modelador de- 
cidir que ferramenta utilizar em cada contexto. 
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Figura 5.4 — Modelo * construído intuitivamente através do plugin por meio de um conjunto de regras. 


A Figura 5.4 representa as fases do modelo criado utilizando o plugin (i* dialogada). 
Em cada etapa descrita na tabela refere-se a uma fase do modelo desenvolvido. As linhas 
1,2 e 3 da Tabela 5.1 representa a primeira fase (1) do modelo desenvolvido. Já as linhas 
5,6,7,8,9e 10, representa a segunda fase (2) do modelo desenvolvido. As linhas 11, 12, 
13,14, 15, 16, 17,18 19, representa a terceira fase (3) do modelo desenvolvido. As linhas 
20, 21 e 22, correspondem à quarta fase (4) do modelo desenvolvido. As linhas 23, 24 e 
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25, correspondem à quinta fase (5) do modelo desenvolvido, e por fim, as linhas 26, 27, 28 
e 29, correspondem à sexta fase (6) do modelo desenvolvido. 


5.6 - TRABALHOS RELACIONADOS 


Esta seção apresenta alguns trabalhos relacionados à tentativa de unificar os 
conceitos dos construtores da linguagem i*. Não conseguimos identificar trabalhos que 
tenham como objetivo um estudo aprofundado da semântica dos construtos da linguagem 
i* e que, ao mesmo tempo, tenham realizado um estudo empírico para validar a pesquisa. 
Os trabalhos existentes fazem um levantamento dos dialetos de i*e propõem ferramentas, 
com base em algumas literaturas mais usadas. Outros trabalhos propõem modelos para 
integrar as variações existentes nos diversos dialetos, bem como novas variações que 
possam surgir. Além disso, essas iniciativas fazem análise comparativa, avaliação e revisão 
de modelos orientados a objetivos. 

Ayala et al., (2005), fazem uma análise comparativa entre os três principais dialetos 
de i* propostos, ou seja, a original da tese de Yu (1995), GRL (Amyot; Mussabacher, 2011) 
e Tropos (Bresciani et al., 2004). Com base nessa análise, o trabalho propõe um modelo 
conceitual genérico para ser utilizado como framework de referência destes tês dialetos. 
Esse modelo é apresentado na Figura 5.5. 

O modelo foi criado incluindo conceitos comuns para i*, tropos e GRL, além dos 
conceitos que não são comuns a esses três dialetos, mas que são importantes para a 
modelagem orientada a agentes. 

De acordo com Ayala et al., (2005), para saber a diferença de um dialeto de i*e o 
framework de referência, define-se operações a serem realizadas no modelo proposto para 
originar tal dialeto. Por exemplo, para originar, a partir do modelo, a versão de i* original 
(Yu, 1995), realiza-se operações tais como: (i) São adicionados os atributos depender . 
strengh e dependee. strengh na classe Dependency. Adicionam-se também as associações 
derivadas dependency equivalence; (ii) Exclui-se classes External Element e sua relação 
com a classe Dependum e Node; entre outras (Ayala et al., 2005). 
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Figura 5.5 — Framework de referência proposto por Ayala. Fonte: Ayala(2005). 


Este modelo originou o metamodelo proposto em Cares (2012), utilizando neste 
capítulo (Figura 5.2) com base do metamodelo compatível com as diretrizes ontológicas. 
A principal preocupação desta iniciativa é a interoperabilidade entre esses dialetos de 
i*, de modo que um modelo feito com base em um dos dialetos possa ser transformado 
em um modelo escrito em outro, de modelo que se possa trabalhar, inclusive com mais 
de uma ferramenta. Já o nosso trabalho tem o objetivo principal de prover orientações 
aos modeladores quanto ao uso dos conceitos núcleo de i*. além disso, o framework de 
referência não inclui informações semânticas sobre os elementos e links, deixando a cargo 
de cada dialeto a decisão de como esses construtos são combinados para gerarem modelos 
bem-formados. Assim, como em tais dialetos ocorrem problemas tais como sobrecarga de 
construtos, redundância de construtos, excesso de construtos e incompletude (abordados 
na seção 3.2), tais problemas são aqui preservados. (Guizzardi; Guizzardi, 2010) apresenta 
exemplos desses problemas em Tropos. . 

Santos (2008) propõe o desenvolvimento de uma ferramenta para modelagem de i*. 
Após um estudo detalhado do i* e da identificação das restrições sobre o uso da linguagem, 
foi proposta uma ferramenta — plugin para o Eclipse — denominada Istar Tool, com o objetivo 
de dar suporte ao desenvolvimento dos modelos i* nas fases de requisitos iniciais e finais 
de Tropos, permitindo a construção de modelos válidos segundo um guia de boas práticas 
do Wiki ;*. Esse trabalho adota uma plataforma de desenvolvimento open source e utiliza o 
framework GMF de modelagem gráfica do Eclipse para implementar a ferramenta. 

O trabalho propõe um metamodelo de ;*, desenvolvido com base nas boas práticas 
e algumas restrições apresentadas no guia do Wiki /*, além de utilizar um catálogo dos 
erros mais comuns na construção de modelos em í * publicado em (Santos, 2008). O autor 
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faz ainda uma comparação entre o metamodelo criado para a ferramenta proposta na 
dissertação e os metamodelos de i* publicados em (Ayala et al., 2005) e (Lucena et al., 
2008), e chega à conclusão de que os dialetos mencionados nesses trabalhos usam o 
mesmo conjunto de elementos que seu trabalho para a criação de modelos i*. As diferenças 
estão nas representações simbólicas (sintaxe concreta) utilizadas para representar 
os elementos e ligações no modelo, e na utilização dos links Meio-fim e nos links de 
contribuição e decomposição. Por exemplo, no Wiki i*, adotado por Santos (2008), o link 
Meio-fim é usado somente de uma tarefa para um objetivo, enquanto que na tese de Yu, e 
na versão Itália, abordadas nos citados trabalhos, o link Meio-fim pode ser usado de Tarefa 
para Softgoal, de Softgoal para Softgoal, de Objetivo para Objetivo, de Tarefa para Objetivo 
e, por fim, de Tarefa para Recurso. Outras variações já foram mencionadas no capítulo 3 
desta dissertação. 

A diferença entre o trabalho de Santos (2008) e o nosso é que o primeiro não tem 
como preocupação a semântica dos construtos da linguagem i*, portanto, as decisões de 
uso dos elementos e links são feitas aleatoriamente. Por exemplo, por que objetivos não 
podem ser decompostos em subobjetivos? Essa decisão, baseada em uma orientação 
do Wiki ;*, não tem qualquer fundamentação. Além disso, algumas distinções não são 
explicitadas, por exemplo, a diferença entre os links Meio-fim e Contribuição Make. 
Novamente, os problemas já levantados na seção 3.2 ocorrem nesta versão de i*. 


5.7 - CONSIDERAÇÕES FINAIS DO CAPÍTULO. 


Neste capítulo, propôs-se meios de apoio automatizados a i* a partir do uso das 
diretrizes ontológicas. As propostas compreendem um metamodelo compatível com as 
diretrizes ontológicas e um plugin de modelagem dialogada que orienta o modelador, 
passo-a-passo, na criação de um modelo i*, também com base nas mesmas diretrizes. A 
ideia é que, como trabalho futuro, o metamodelo sirva de base para o desenvolvimento de 
uma ferramenta de modelagem i*, que contenha o plugin como um recurso de auxílio ao 
modelador. 

O capítulo se inicia apresentando conceitos sobre metamodelagem, ressaltando as 
vantagens do uso de metamodelos como base para a criação de software. Apresentou-se, 
também, exemplos de ferramentas de modelagem em i* que fazem o uso dessa prática. 

Em seguida, discutiu-se o modelo proposto por Cares (2012), que compreende os 
conceitos núcleo de i*, tendo sido criado com base em vários de seus dialetos. Esse modelo 
serviu de base para a criação do metamodelo proposto neste capítulo. 

A proposta do plugin surgiu da constatação de que um metamodelo não é capaz de 
formalizar todas as diretrizes ontológicas, pois não inclui informações semânticas. O público 
alvo desse plugin consiste em modeladores iniciantes em i*, que podem ir aprendendo o 
uso da linguagem, conforme constroem seus modelos. Procurou-se, nesse plugin, criar 
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um diálogo que equilibrasse o fornecimento de orientações e a liberdade de modelagem. 
Mesmo assim, reconhecemos que é preciso disponibilizar diferentes recursos, mais e 
menos intrusivos, dependendo do nível de conhecimento do modelador. Modeladores mais 
experientes podem, por exemplo, preferir um verificador que funcione após todo o modelo 
tenha sido construído. É claro que informações seguras sobre o uso de tais recursos só 
poderão ser obtidas após a implementação e experimentação da ferramenta, eventualmente 
realizando-se estudo empírico nos moldes do que propusemos no capítulo 4. 

Este capítulo analisa, ainda, alguns trabalhos relacionados quanto ao apoio 
automatizado para a modelagem i*. Dentre as diversas ferramentas e trabalhos nessa 
direção, selecionou-se aqueles que têm em vista a existência de múltiplos dialetos 
e, portanto, a necessidade de orientar o modelador quanto ao uso dos construtos da 
linguagem. Além da descrição, provimos uma discussão sobre as principais diferenças 
dessas iniciativas e o trabalho aqui apresentado. 
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CAPÍTULO 6 
CONCLUSÃO E TRABALHOS FUTUROS 


Este capítulo apresenta as conclusões do trabalho conduzido nesta dissertação; na seção 6.1, 
são descritas as contribuições da dissertação e na seção 6.2, são apresentadas perspectivas 
de trabalhos futuros. 


6.1 - CONTRIBUIÇÃO DESTA DISSERTAÇÃO 


Com o crescimento da linguagem i*, e consequentemente da comunidade que a 
desenvolve, vários problemas surgiram na aplicação da linguagem. Pesquisadores utilizam 
conceitos com significados diferentes ou até mesmo conflitantes. Com a necessidade de 
esclarecer a semântica dos conceitos da linguagem |*, houve a necessidade de criar uma 
ontologia comum para os principais conceitos da linguagem (Guizzardi et al., 2013a, 2013b) 
(Guizzardi; Franch; Guizzardi, 2012). Porém, era preciso confirmar a intuição de que essa 
ontologia comum e as diretrizes de modelagem delas derivadas eram realmente úteis 
na construção de modelos i*. A partir dessa motivação, houve a necessidade de validar 
as diretrizes ontológicas através de aplicação de um experimento. Os resultados deste 
experimento são a maior contribuição desta dissertação. 

No citado experimento, foi avaliado se as diretrizes ontológicas são úteis ou se não 
tinha qualquer tipo de efeito para auxiliar na construção de modelos i*. Ele foi aplicado em 
duas instituições de ensino superior localizado no estado do Espírito Santo-ES. 

No experimento, os participantes receberam a descrição de um problema, junto 
a um diagrama de Razão Estratégica i*, modelando tal problema, porém com algumas 
lacunas. Os participantes deveriam, então, completar o modelo conforme os conceitos 
vistos no experimento e, por fim, responder um questionário que tinha como objetivo colher 
dos participantes, a justificativa para a escolha de um determinado elemento ou link para 
cada lacuna do modelo. Essa mesma atividade foi realizada sem e com o uso das diretrizes 
ontológicas e, depois, comparam-se os modelos com o modelo gabarito esperado. 

Após ambas as aplicações, analisamos os efeitos das diretrizes ontológicas na 
utilização na construção de modelos i*. A princípio, como ambas as aplicações foram 
realizadas seguindo o mesmo projeto do experimento, era nossa intenção analisar os 
dados em conjunto. Porém, notou-se que havia divergência nos resultados das aplicações, 
o que nos levou a analisar os dados separadamente. Na análise realizada no grupo de 
alunos dos cursos de Ciência da Computação, Engenharia da Computação, Mestrando 
em Informática e Doutorando em Ciência da Computação (aplicação 1), o teste estatístico 
de Mann-Whitney comprovou que as diretrizes ontológicas são úteis na construção de 
modelos i*. Entretanto, na análise realizada em um grupo de alunos do curso de Tecnologia 
em Análise e Desenvolvimento de Sistemas (aplicação 2), esse mesmo teste não permitiu 
determinar uma correlação entre o uso das diretrizes e a criação de modelos mais próximos 
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A diferença dos resultados dos experimentos realizados em ambas as instituições 
de ensino superior, pode ser explicada pela diferença no perfil dos participantes dos 
experimentos. Na aplicação 1, os participantes tinham maior grau de instruções que os 
participantes da aplicação 2 e, consequentemente, mais experiência em modelagem 
conceitual. 

Portanto, a conclusão do experimento é que as diretrizes ontológicas são úteis para 
modeladores experientes e novos estudos empíricos devem ser realizados para confirmar 
a nossa hipótese. 

Além da conclusão principal, o experimento também permitiu-nos concluir que 
as diretrizes ontológicas não levam a uma diminuição no tempo de criação de modelos. 
Isso não era esperado, já que tais diretrizes provêm uma orientação específica sobre que 
elemento ou link i* usar em cada situação. Analisou-se também que questões (lacunas) 
trouxeram mais dificuldades, com o principal objetivo de identificar que as diretrizes 
ontológicas precisam ser ainda melhoradas. E, por fim, fez-se uma análise da percepção 
que os participantes tiveram da utilidade das diretrizes ontológicas na criação de modelos 
i*, O que, em geral, pode-se afirmar que foi positiva. 

Para que as diretrizes ontológicas possam fazer a diferença efetiva na prática na 
construção de modelos i*, é preciso que elas estejam embutidas em sistema de apoio 
a modelagem desta linguagem. Assim surgiu a necessidade de ter como ideia a criação 
de um plugin que auxiliasse no desenvolvimento de modelos i* através de diálogos 
com o modelador, fornecendo as orientações e a liberdade de modelagem. Sendo útil 
no aprendizado para modeladores iniciantes conforme a criação do modelo, além de 
auxiliar os desenvolvedores mais experientes através da validação do modelo depois de 
desenvolvido de acordo com as diretrizes ontológicas. Esse plugin não foi validado por um 
experimento, pela simples razão dele ser um protótipo e não uma ferramenta. O motivo de 
ele ser um protótipo se dá pelo fato do pouco tempo para o seu desenvolvimento, ficando 
para trabalhos futuros. 


6.2 - TRABALHOS FUTUROS 


Para trabalho futuro, em primeiro lugar, propõe-se a aplicação do experimento 
aqui projetado em grupo de pesquisa de diferentes regiões e com perfis diferentes, para 
validarmos o nosso estudo. É preciso projetar outros experimentos, por exemplo, um 
experimento que os participantes criem modelos i* do zero, sem e com o uso das diretrizes 
ontológicas, modelos estes que seriam posteriormente avaliados por critérios definidos por 
uma equipe de especialistas, pertencentes a vários grupos de pesquisas da comunidade 
f*. A princípio, esse era o tipo de experimento que planejávamos desenvolver, mas seria um 
experimento mais arriscado, com muitas variáveis e que, talvez não levasse a resultados 


concretos. Ou seja, o motivo dos participantes preencherem as lacunas no modelo, é pela 
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razão, por quais os participantes que nunca tiveram conhecimento em modelagem se 
sentisse desmotivado em realizar a atividade por não ter tal conhecimento. Outra razão foi 
pelo simples motivo de direcionarmos quais elementos/links estaríamos analisando. Porém, 
acreditamos que observando os resultados do experimento aqui realizado nos forneçam 
informações que auxiliem no projeto de um experimento nesta nova direção. 

Outro objetivo, a partir de agora, é criar uma ferramenta de modelagem de i*, 
com base nos resultados do capítulo 5, ou seja, metamodelo e plugin propostos. Isso 
contribuirá para o uso prático das diretrizes ontológicas e abrirá novas oportunidades de 
experimentação. Além de realizar um experimento para validar se a utilização do plugin, 
verificando se o plugin traz benefício para os modeladores iniciantes. O experimento não 
foi realizado nesse intuito, devido à falta de tempo para desenvolvimento do plugin e o 
mesmo, ter sido desenvolvido como protótipo. 

Por fim, outra questão importante é aprofundar a discussão sobre as diretrizes 
ontológicas dentro da comunidade i*. para que elas façam a diferença no uso da linguagem, 
é necessário que elas sejam aceitas pelos membros da comunidade. Reconhecemos 
que as diretrizes como estão hoje são fruto da interpretação de um pequeno grupo de 
pesquisadores, com base em suas próprias leituras e experiências. De forma, segui-las 
apenas seria definir mais um dialeto i*, o que não atende aos propósitos do que se destinam. 
O que se propõe é a criação de diretrizes, com base em uma ontologia comum, para que 
fique explícita a semântica dos construtos da linguagem. Em outras palavras, o que importa 
é a abordagem de utilizar ontologias para orientar o uso dos construtos de i*, qualquer que 
seja o conjunto final de diretrizes ontológicas. Esta dissertação dá mais um passo para 
mostrar a validade dessa abordagem, mostrando por meio de um estudo empírico, que 


essas diretrizes são úteis na prática, pelo menos para modeladores experientes. 
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APÊNDICES 


APÊNDICE A — FRAMEWORK 


Preliminary information 


Abstract 


Nowadays, the community that develops i* is relatively big and these developers, who are geographically 
dispersed, tend to ascribe different (and sometimes conflicting) meanings to its constructs. It is argued 
that this flexibility is part of the framework's own nature, and in fact may be considered one of its key 
success features. But on the other hand, it is our belief that this represents a barrier in terms of promoting 
the framework, creating serious issues, such as: a) hampering the efficient communication of knowledge 
among experts of the community; b) increasing the learning curve of newcomers; and c) inhibiting the 
adoption of the ffamework by practitioners. In the past few years, the community has become aware of 
this problem and several attempts have been made for facilitating the access and uniform use of the i* 
language. Although we recognize that there are significant outcomes of these works (e.g. pointing out 
the applied concepts in particular variations; showing the author's view on how concepts relate), these 
attempts did not quite succeed in providing interoperability, simply because the proposed approaches are 
valuable in clarifying the language's syntax while being very limited in terms of providing an understanding 
of its semantics. Going beyond syntactic issues, since 2006, we are involved in an attempt to define a 
common ontology (thus, providing real-world semantics) for the core concepts of the i* language. We 
believe this may assist in clarifying the semantics of the language's concepts, thus generating a number of 
ontological modeling guidelines. targeted at enhancing the language's usability. After the semantics behind 
the i* constructs have been theoretically understood, it is now time to validate our intuitions in practice. 
Thus, with this empirical study, we aim at check if all of the participants will are able to utilize the ontology 
guidelines to do the models. If the what we are developing facilitates the development of the model, or 
still confuses more the development. i.e., if the perception of the participants, about the guideline, will 
be helpful or not. For that, we propose an experiment in which we compare the models designed by two 


groups: one applying the ontological guidelines while the other does not have any knowledge of such 


guidelines. 

Objectives 

General Validate if the ontological guidelines developed by Guizzardi, Franch, 
Guizzardi and Wieringa (2006-2013) (please refer to the bibliographic 
references in this document) help or confuses more the development 
of the i* models. 

Specific In order to draw conclusions regarding the general objective, we aim at 


measuring: 

The ontology guidelines are helpful or not. 

Time spent designing the models with and without the use of ontological 
guidelines. 

Opinion of the experiment participants regarding the usefulness of the 
ontological guidelines. 
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Research Questions and Metrics 


Are the modeling activities done faster when the guidelines are provided to the participants? 


Are the ontological guidelines perceived as useful by the participants? 


Experiment Detailed Plan 


Object/Unity of Study 


Goal models developed using |* 
Factor(s) 


Alternative of factors 


Constructors of language i* 


Making use or not of ontology guidelines. 


Subjects / Experiment Participants 


The participants are students from two collage in state of Espírito Santo-ES , some students courses 


of Technological Analyses and Development of Systems and undergraduate Computer Science and 


Computer Engineering, master's degree and PhD. 


Group Selection Strategy 


the participants fill in two online forms: the Term of Consent 
and the Participant Profile Form. The participants are 
randomly selected to the control and experiment groups The 
control group is formed by half of the participants who will not 
receive any instruction regarding the ontological guidelines, 
serving as basis for comparison with the experiment group. 
The experiment group will learn how to use the ontological 
guidelines through an activity during the experiment tasks, 
they will be simply called groups A and B, respectively. 


Forms / Terms / Material 


Content 


[X] Term of Consent 


Aims at formalizing the participant's agreement in voluntarily 
taking part in the experiment tasks. 


[X] Participant Profile Form 


Aims at obtaining from the participant, a set of data that will 
assist in the interpretation and analysis of the experiment 


results. 


[X] Evaluation Questionnaire 


Aims at obtaining information regarding how the ontological 
guidelines assist the participant, as well as his/her opinion 
regarding the usefulness of these guidelines. 


[X] Supporting Material 


Aims at conveying the participants with information about the 
experiment and about the use of the ontological guidelines. 


Participation Pre-conditions 


Have previous knowledge about i* 


Research Approach 


[ ] Qualitative 


[X] Quantitative 


To validate if the ontological guidelines are helpful or not in 
the development of i* models, and check if the participants 


are able to utilize the ontological guidelines. 


Method 


Justification 
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[X ]in-vitro Developed in a controlled environment. 

[ Jin-vivo Developed in the real environment. 

[ Jin-virtuo Developed through a computer simulation. 

[ Jin-silico Developed with mathematical models without human 
interaction. 


Experiment Detailed Plan 


Instruction Design 


The experiment is composed of four steps: 

Step 1: the participants will fill in two online forms: the Term of Consent and the Participant Profile Form. 
The participants are randomly selected to the control (group A) and experiment groups (group B). 

Step 2: a brief lecture about i*is given to the participants of both groups with the purpose of ensuring a 
common understanding. Then, they are asked to complete an i* model concerning modeling problem | 
(pre test). 

Step 3: a lecture is presented to the participants in the experiment group about the use of ontological 
guidelines to assist in the design of i* models. 

Step 4: Then, both groups are asked to complete an /* model concerning modeling problem II (post test). 


Data/Time Experiment Task 

18/03 — 15:00 — 15:20 Instructions for participant and raffle of groups (A and B). 
18/03 — 15:20 — 15:40hs Review about framework i* for groups A and B. 

18/03 — 15:40 — 16:10hs Application of the pre-test for groups A and B. 

18/03 — 16:00 — 16:20hs Presentation of the ontology guidelines only for group A. 
18/03 — 16:20 — 17:00hs Application of the pos-test for groups A and B. 


Table 1. Experiment Schedule 


APÊNDICE B - PLANO DE ANÁLISE DE RESULTADOS 


Result Analysis Plan 


Hypotheses Description 
HO The ontological guidelines aren't perceived as useful by the modeler. 
Hi The ontological guidelines are perceived as useful by the modeler. 
H2 The use of ontological guidelines does not accelerate the process of 


creating models |”. 


H3 The use of ontological guidelines accelerates the process of creating 

models j* 
Hypotheses Metrics 

HO given by the participants regarding the not usefulness of the ontological 
guidelines. 

H1 given by the participants regarding the usefulness of the ontological 
guidelines. 
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H2 


time spent in the development of the models designed without the use 
of the ontological guidelines; 


H3 


time spent in the development of the models designed with the use of 
the ontological guidelines. 


Dependent Variable 


Description 


Variable 1 Grades of the models of the participants in the pre-test. 
Variable 2 Grades of the models of the participants in the post-test. 
Validity Evaluation 
Threat Description 

Threat 1 Participants' heterogeneity. Action: evaluate heterogeneity by 
considering different academic degrees (undergraduate vs. graduate 
students) and academic performance. 

Threat 2 Participants already have knowledge of the ontological guidelines. 
Action: add question in the Participant Profile Form asking if the 
participant has had previous contact with the ontological guidelines. 

Threat 3 The participants may not be interested in the experiment, performing 
the tasks without care for the result. Action: motivating the participants, 
clearly showing the context and possible effects of the experiment. 

Threat 4 The participants can study between pre-test and post-test. Action: inform 
the participants of the importance of not studying during the experiment, 
so as not to influence the results. 

Threat 5 Effect of tasks' simplicity/complexity: develop experiment tasks that are 
neither so easy nor too complex to the participants. 

Threat 6 Experiment instructor effect. Actions: use the same lecture slides for the 
participants of both Universities, try to be as clear as possible, try not to 
influence the results. 

Threat 7 Effect of how the ontological guidelines are presented. Actions: write 


ontological guidelines clearly, use examples to illustrate. 


Population Parameters 


Justification 


[X] Parametric 


The population distribution is equal and the experiment is performed 
with more than 20 participants. 


[ | Non-parametric 


The goal of the study is to compare the result of the experiment group 
with the control group, resulting in a non-equally distributed population. 
Moreover, the number of participants is inferior to 20. 


Used Test 


Justification 


Mann-Whitney 


This is a non-parametric statistic method. Moreover, according to this 
test, the samples should be extracted from the same population and the 


observations are comparable. 
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Data Set Reduction 


A dispersion diagram will be built to help us identify disperse points which can be analysed an possibly 
disregarded in the result interpretation. 


Specification of operation of the experiment 


Materials Materials used: 
* Computer; 

* Datashow; 

- Broad; 

* Lab. 


Comitment Information about the interest and commitment of the participants will be 


obtained in profile questionnaire. 


Data collection Study data will be collected through answer of the participants in test. This 
dada will be transferred for a spreadsheet that will perform the necessary 


calculations. 
Evironment Study will occur in the classroom of the two College. 
Validity Understanding of participants will be validated through question that will be 


answered on questionnaire of evaluation, that will be applied after respective 


activity in classroom. 


Conformity A researcher will accompany all activity, in order to guarantee study was 


realized on conformity with planned. 
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APÊNDICE C - TERMO DE CONSENTIMENTO LIVRE E ESCLARECIDO 


UFES (Universidade Federal do Espírito Santo) 
NEMO (Ontology & Conceptual Modeling Research Group) 
Validação das diretrizes ontológicas para a construção de modelos usando i* 


nemo Estudo empírico 


Termo de Consentimento Livre e Esclarecido 


Você está convidado a participar do estudo empírico intitulado “Validação das diretrizes ontológicas 
para a construção de modelos usando j*”. 

O objetivo deste estudo é propor o uso/desenvolvimento de modelos conceituais utilizando a 
linguagem i* com ajuda de diretrizes ontológicas. Para isso, está prevista a realização de uma série de 
experimentos, que envolvem a elaboração e/ou a interpretação de modelos conceituais. 

Este convite é devido à sua matrícula em disciplina ofertada pelo DI / CT/ UFES no semestre de 
2015/1, e sua participação não é obrigatória. A qualquer momento você pode desistir e retirar seu 
consentimento. 

Sua participação neste estudo empírico consistirá de preencher alguns questionários (de perfil, 
avaliações de atividades, entre outros), interpretar modelos conceituais. As atividades podem mudar, 
dependendo do experimento que estiver sendo realizado. 

O estudo empírico ocorrerá nas instalações da UFES, no CT-VI na sala de aula (114), em horário de 
aula da disciplina “Desenvolvimento Web e Web Semântica”, com duração de aproximadamente de 2 
horas. 

A sua participação no experimento será como voluntário, não recebendo nenhum privilégio, seja ele de 
caráter financeiro ou de qualquer natureza. Entretanto, lhes serão garantidos os cuidados necessários 
à sua participação de acordo com seus direitos individuais e respeito ao seu bem-estar físico e 
psicológico. 

Não há nenhum risco relacionado à sua participação na pesquisa. 

Os benefícios relacionados com sua participação são aquisição de experiência em modelagem 
conceitual e auxílio em projeto de pesquisa desenvolvidos pelo grupo NEMO. 

As informações obtidas através dessa pesquisa serão confidenciais e asseguramos o sigilo sobre sua 
participação. 

Os responsáveis pela pesquisa desde já agradecem a sua participação e valiosa contribuição com o 
trabalho. 

Os resultados da pesquisa serão encaminhados aos participantes, entre outros, para fins de 
divulgação. 


Nome e assinatura do 
pesquisador responsável | Ramilton Costa Gomes Júnior, Mestrando PPGI/UFES 

(e-mail: ramilton costa Whotmail.com) 

CEP (Comitê de Ética em Av. Fernando Ferrari, 514, Goiabeiras | Vitória - ES - Cep: 29.075-910 


Pesquisa) da UFES Tel: +55 (27)xxx — email: xxx 
Participante da Pesquisa Declaro que entendi os objetivos, riscos e benefícios de minha 
participação no experimento e concordo em participar, 
Assinatura: 
Nome: 
Local: Data: / / 
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APÊNDICE D = QUESTIONÁRIO SOBRE PERFIL DO PARTICIPANTE DO 
ESTUDO EMPIRICO 


NEMO (Ontology & Conceptual Modeling Research Group) 
UFES (Universidade Federal do Espírito Santo) 
Validação das diretrizes ontológicas para a construção de modelos usando i* 


nemo Estudo empírico 


Questionário sobre Perfil de Participante de Estudo Empírico 


Nome 


e-mail Grupo Número 


Grau de Formação Acadêmica (marque a maior titulação e indique se está Completo / Incompleto) 


O Ensino Médio Superior [Especialização [Mestrado [ Doutorado 


O Completo | Incompleto 


Formação Acadêmica (curso/área) (da maior titulação indicada) 


Tempo de Experiência em Modelagem de Objetivos 


O Não possui [Menos de 1 ano Entre 1 anoe3anos Mais de 3 anos 


Se possui experiência em Modelagem de Objetivos, de que forma ela foi adquirida? 


O Curso Qual(is) / duração? 
Outras linguagens de i* 
O Disciplina  Qual(is) / duração? 


O Projeto (Pesquisa, TCC, Extensão, Iniciação Científica ou similar) 


Se possui experiência em Modelagem de objetivos, descreva sucintamente o(s) projeto(s) principal(is) 
desenvolvido(s) — projeto, contexto e atividades 


Tempo de Experiência em /* 


O Não possui [lNMenosde1 ano [Entrei anoe3anos [ Mais de 3 anos 


Se possui experiência em /*, de que forma ela foi adquirida? 


OD Curso Qual(is) / duração? 
O Disciplina  Qual(is) / duração? 


O Projeto (Pesquisa, TCC, Extensão, Iniciação Científica ou similar) 


Se possui experiência em /*, descreva sucintamente o(s) projeto(s) principal(is) desenvolvido(s) — 
projeto, contexto e atividades. 


Assinatura 
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APÊNDICE E — INSTRUÇÕES E FORMULÁRIO PARA REALIZAÇÃO DA 
ATIVIDADE -— PRÉ-TESTE 


UFES (Universidade Federal do Espírito Santo) 
NEMO (Ontology & Conceptual Modeling Research Group) 
Validação das diretrizes ontológicas para a construção de modelos usando i* 


nemo Estudo empírico 


Instruções e Formulário para realização da atividade 


Número de Identificação 


Caro participante, 

Solicitamos a leitura das instruções aqui presentes antes da execução da atividade. Caso haja dúvidas, 
por favor, questionar aos pesquisadores responsáveis antes do início. Não devem ocorrer conversas 
paralelas entre os participantes. 

Para a realização da atividade, será apresentado um modelo i* de um determinado domínio, onde o 
participante terá que complementar as lacunas faltantes, determinando que elemento ou link de i* é 
apropriado para cada situação. O modelo deverá ser resolvido no formulário apresentado como parte 
deste documento. Apenas o uso das definições de i* entregues em papel, papel e caneta/lápis, além 
das instruções aqui descritas, são necessários. 

Após a realização desta tarefa, cada participante será solicitado a preencher um outro formulário, em 
que apresentará as razões para a escolha de determinado elemento ou link de i* para cada caso. 
Solicitamos que todas as informações presentes no documento sejam devidamente preenchidas, na 
ordem em que elas são solicitadas. Em particular, por favor registre a hora de início e fim da atividade 
em campo determinado neste documento. 

Passos previstos para esta etapa do experimento: 


1. Explicação sobre os procedimentos do experimento; 


2. Identificação do número de cada participante e realização de sorteio para agrupamento dos 
participantes. Serão considerados dois grupos (A, B); 


3. Distribuição das instruções e formulários; 


4. Resposta ao formulário da atividade, de acordo com os itens solicitados; 


5. Entrega do formulário devidamente preenchido. 


DOMÍNIO 1 
A) Enunciado do problema: 


Um fabricante de equipamentos eletrônicos criou um serviço de manutenção para consertar 
dispositivos incluídos em sua política de garantia. Para isso, ele conta com um Call Center para 
responder às queixas dos clientes. O Call Center recebe as reclamações dos clientes, que explicam o 
problema que eles têm com o máximo de detalhes possível. Se o problema for genuíno (ou seja, não 
for resultado da má utilização do aparelho) e o dispositivo se enquadrar nas políticas de garantia da 
empresa, o Call Center direciona o cliente para o canal adequado dentro da empresa, de modo que o 
dispositivo possa ser consertado. Para diversificar o seu serviço, o Call Center recebe queixas tanto 
por telefone quanto por e-mail. Por telefone, a interação com o cliente é geralmente mais fácil, o que 
resulta em uma descrição mais completa do problema. Por outro lado, analisando e-mails leva metade 
do tempo, quando comparado com o atendimento de chamadas telefônicas. A fim de identificar o mau 
funcionamento do aparelho, o pessoal do Call Center geralmente consulta um repositório que auxilia 
no diagnóstico do problema de acordo com falhas específicas a cada dispositivos. 
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APÊNDICE F — QUESTIONÁRIO DE ATIVIDADES PRÉ-TESTE 


UFES (Universidade Federal do Espírito Santo) 
NEMO (Ontology & Conceptual Modeling Research Group) 
Validação das diretrizes ontológicas para a construção de modelos usando i* 
nemo Estudo empírico 
Atividade 1 — Escolha dos elementos e links em um modelo i* 
Questionário de Atividades 
Grupo Número Início Fim 
Il. Por favor, forneça a razão para a escolha de um determinado elemento intencional ou 
link /* nos seguintes casos a partir do diagrama: 
01 
02 
03 
04 
05 
06 
07 
08 
09 
10 
1 
HI. As orientações do wiki de i* (vistos na primeira apresentação) são úteis na 
construção de modelos ;*? 
O Muito útil [ Um pouco útil Indiferente [O Não muito útil [1 Não é útil a todo 
Comentário 
HI. Você está ciente de qualquer outro tipo de orientação para ajudar na construção 
de modelos i*? 
DO Sim Fontes das orientações: O Não 
Iv. Como você teve acesso a essas orientações? 
D Disciplina na graduação, mestrado ou doutorado Dl Leitura de artigos D Participação 
de projetos 
Outros 
V. Se você respondeu “Sim” em questão III, por favor, diga-nos como você compara 
as orientações do wiki de i* com o que você sabia anteriormente? 
L Melhor [Mesma qualidade Pior 
V Comentários adicionais/Sugestões 
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APÊNDICE G - INSTRUÇÕES E FORMULÁRIO PARA REALIZAÇÃO DA 
ATIVIDADE - PÓS-TESTE CONTROLE 


UFES (Universidade Federal do Espírito Santo) 
NEMO (Ontology & Conceptual Modeling Research Group) 
Validação das diretrizes ontológicas para a construção de modelos usando i* 


nemo Estudo empírico 


Instruções e Formulário para realização da atividade 


Número de Identificação 


Instruções 


Caro participante, 

Solicitamos, mais uma vez, a leitura das instruções aqui presentes antes da execução da atividade. 
Caso haja dúvidas, por favor, questionar aos pesquisadores responsáveis antes do início. Não devem 
ocorrer conversas paralelas entre os participantes. 

Esta atividade será realizada nos mesmos moldes da anterior, ou seja, será apresentado um modelo 
i* de um determinado domínio, onde o participante terá que complementar as lacunas faltantes, 
determinando que elemento ou link de i* é apropriado para cada situação. Como anteriormente, o 
modelo deverá ser resolvido no formulário apresentado como parte deste documento. O material de 
uso nesta tarefa compreende apenas as definições de i* entregues em papel, papel e caneta/lápis, 
além das instruções aqui descritas. 

Como na etapa anterior, após a realização desta tarefa, cada participante será solicitado a preencher 
um outro formulário, em que apresentará as razões para a escolha de determinado elemento ou link 
de i* para cada caso. 

Solicitamos, mais uma vez, que todas as informações presentes no documento sejam devidamente 
preenchidas, na ordem em que elas são solicitadas. Em particular, por favor registre a hora de início e 
fim da atividade em campo determinado neste documento. 

Passos previstos: 

Distribuição das instruções e formulários; 

Resposta ao formulário da atividade, de acordo com os itens solicitados; 

Entrega do formulário devidamente preenchido. 


DOMÍNIO 1 Horário Início Hora Fim 
A) Enunciado do problema: 


O organizador de um Mercado de Natal está planejando os preparativos para o evento. Ele está 
preocupado tanto com o lucro e com sua reputação, como com o fato de que o mercado de Natal 
atrai muitos turistas para a cidade. O organizador deve fornecer os estandes onde os vendedores 
irão organizar e vender os seus produtos, sendo responsável, ainda, por selecionar quais tipos 
de vendedores atrairão mais clientes para o mercado. Uma coisa importante é equilibrar o tipo de 
produtos que são vendidos. Decoração de Natal, por exemplo, é essencial em um mercado como 
este, assim alguns fornecedores deste tipo de produto têm que ser selecionados. Como alguns dos 
produtos adquiridos no mercado são os presentes, também deve haver uma solução para embrulhar 
presentes de Natal. A este respeito, há duas opções: ou o organizador fornece um estande especial 
especificamente para embrulhar os presentes, ou ele deixa os vendedores prover soluções individuais 
para esta questão. Por mais que o organizador queira reduzir custo e responsabilidade (favorecendo, 
assim, a segunda opção), ele também deseja garantir qualidade e uniformidade no embrulho de 
presentes, o que proporcionará mais visibilidade para o mercado de Natal. 
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APÊNDICE H - QUESTIONÁRIO DE ATIVIDADES PÓS-TESTE CONTROLE 


nemo 


Atividade 1 — Escolha dos elementos e links em um modelo ;* 


UFES (Universidade Federal do Espírito Santo) 
NEMO (Ontology & Conceptual Modeling Research Group) 
Validação das diretrizes ontológicas para a construção de modelos usando i* 
Estudo empírico 


Instruções e Formulário para realização da atividade 


Questionário de Atividades 


Grupo 


Número 


Início 


Fim 


I. Por favor, forneça a razão para a escolha de um determinado elemento intencional ou link 
i* nos seguintes casos a partir do diagrama: 


13 


14 
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APÊNDICE | - INSTRUÇÕES E FORMULÁRIO PARA REALIZAÇÃO DA 
ATIVIDADE - PÓS-TESTE EXPERIMENTAL 


UFES (Universidade Federal do Espírito Santo) 
NEMO (Ontology & Conceptual Modeling Research Group) 
Validação das diretrizes ontológicas para a construção de modelos usando i* 


nemo Estudo empírico 


Instruções e Formulário para realização da atividade 


Número de Identificação 


Instruções 


Caro participante, 

Solicitamos a leitura das instruções aqui presentes antes da execução da atividade. Caso haja dúvidas, 
por favor, questionar aos pesquisadores responsáveis antes do início da mesma. Não devem ocorrer 
conversas paralelas entre os participantes. 

A atividade consistirá no preenchimento de um modelo i* utilizando conceitos apresentadas na 
linguagem i*. Para a realização da atividade será apresentado um modelo de um determinado 
domínio, onde o participante terá que complementar as lacunas faltantes utilizando os conceitos de i* 
apresentado em sala de aula. O modelo deverá ser resolvido em local próprio reservado para esse fim. 
Apenas o uso do papel e caneta/lápis, além das instruções aqui descritas, são necessários. 

A intenção é avaliar como os modelos são desenvolvidos com a utilização das diretrizes ontológicas 
entre os elementos e links da linguagem. 

Terá um formulário de avaliação complementar. Para fins de coleta de informações sobre como o 
modelador pensou nos conceitos e i* para complementar o modelo. 

Solicitamos que todas as informações presentes no documento sejam devidamente preenchidas, na 
ordem em que elas são solicitadas. 

Passos previstos: 

Explicação sobre os procedimentos do experimento; 

Identificação do número de cada participante e realização de sorteio para agrupamento dos 
participantes. Serão considerados dois grupos (A, B); 

Distribuição das instruções + formulário de acordo com o grupo sorteado; 

Resposta ao formulário da atividade, de acordo com os itens solicitados; 

Entrega do formulário devidamente preenchido. 


DOMÍNIO 1 Horário Início Hora Fim 


A) Enunciado do problema: 


O organizador do Mercado de Natal está ocupado com os preparativos para o evento. Ele está 
preocupado tanto sobre o lucro e reputação, como o mercado de Natal atrai muitos turistas para a 
cidade. O organizador deve fornecer os estandes onde os vendedores irão organizar e vender os 
seus produtos. E ele também deve selecionar quais tipos de vendedores iria atrair mais clientes para 
o mercado. Uma coisa importante é equilibrar o tipo de produtos que são vendidos. Decoração de 
Natal, por exemplo, é uma necessidade para alguns fornecedores para este tipo de produto tem 
que ser selecionada. Como alguns dos produtos adquiridos no mercado são os presentes, também 
deve haver uma solução para embrulhar presentes de Natal. A este respeito, há duas opções: ou o 
organizador fornece um estande especial especificamente para embrulhar os presentes, ou ele deixa 
os vendedores lidar com este problema eles mesmos. Por mais que o organizador gostaria de ter um 
custo menor e responsabilidade (favorecendo, assim, a segunda opção), proporcionando uma película 
apresenta ficar mais garantias de qualidade e uniformidade nos envolvimentos, o que proporciona 
mais visibilidade para o mercado de Natal. 
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APÊNDICE J — QUESTIONÁRIO DE ATIVIDADES PÓS-TESTE EXPERIMENTAL 


UFES (Universidade Federal do Espírito Santo) 
NEMO (Ontology & Conceptual Modeling Research Group) 
Validação das diretrizes ontológicas para a construção de modelos usando i* 
Estudo empírico 


Atividade 1 — Escolha dos elementos e links em um modelo i* 


Questionário de Atividades 


Por favor, forneça a razão para a escolha de um determinado elemento intencional 
ou link i*nos seguintes casos a partir do diagrama: 


As orientações ontológicas (aprendidas na segunda apresentação) são úteis na 
construção de modelos ;*? 


O Muito útil 


O Um pouco útil [Indiferente [O Não muito útil [ Não é útil a todo 


Comentário 


Faça uma comparação da Wiki i* com as orientações ontológicas aprendidas na 
segunda apresentação. 


Melhor DO 


Mesma qualidade Pior 


IV. 


Comentários adicionais/Sugestões 
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APÊNDICE K —- CONTEÚDO DA AULA SOBRE /* FRAMEWORK 


Agenda há 
Introdução 
O ' Elementos intencionais e links de i* 


O O it Framework 


Ramilton Gomes 
Introdução o 


nemo Renata Guizzardi 


* Modelagem de objetivos surgiu mais ou menos em 1993. 
* Concentra-se nos estágios inicias de requisitos, visando: 
Modelar problemas de um ator individual ou 
organização; 
Delinear uma solução capturando um conjunto de 
objetivos. 
Decumenta objetivos e outros elementos intencionais 


ça 
Elementos e links de i* 
“ON 
— em 
: Coteans End ini 
- - 2 He 
E 
Elementos as Elementos = 
Ex. Ator 


Ator - Entidades que possuem objetivos e realizam ações para 
alcançar esses objetivos, exercendo o seu know-how. Ator 
E 
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Elementos e 


bjetivo - Representa o desejo intencional de um ator. Os 
etalhes de como o objetivo é satisfeito não é descrito pelo 
bjetivo. Portanto, pode ser descrito através da decomposição 
e tarefas. 


ooo 


Elementos 


| Ex. Objetivo 


Elementos 


Softgoal - Softgoal é semelhante ao objetivo, exceto que os 
critérios para a satisfação do objetivo não são claros, ele é 
considerado suficientemente satisfeito do ponto de vista do 


Or. 


Elementos 


Ex. softgoal 


EM 
E 


Gu 
CE» 


Elementos 


Recurso - entidade física ou informacional usada pelo ator. Este 
tipo de elemento assume que não há questões em aberto, ou 
perguntas a respeito de como a entidade será alcançada. 


Elementos 
Ex. Recurso 


Links a 


Means-Ends Link - Este link aponta para uma relação entre um 
fim, e um meio para alcançá-la. Por exemplo, um meio pode ser 
uma tarefa e um fim pode ser um objetivo. 


Links do 


Decomposição - Uma tarefa é vinculada ao seu nó por links de 
decomposição. Uma tarefa pode ser decomposta em quatro 

tipos delementos: um subobjetivo, umsubtarefa, um 
recurso, e/ou um softgoal. 


Links aa 


Decomposição 'Tarefa-Objetivo: Subobjetivo. Nestpo de 
decomposição, não é especificado como o subobjetivo deve ser 
alcançado, permitindo que alternativas sejam consideradas 


Becomposição Tarefa-Tarefa: Subtarefa. Quando uma 
subtarefa é especificadamo um subcomponente 
tarefa, detalhando como a tarefa é realizada. 


de uma 


Links = 


Becomposição Tarefa-Softgoal: SoftgoalFoQuando um 

softgoal é um componente de uma decomposição de tarefas, 
eles servem como um objetivo de qualidade para essa tarefa, e, 
assim, orienta (ou restringe) a seleção entre alternativas em 


decomposição. 


Links » 
And-Decomposition - Qai 
descendentes estão satisfeito 


é satisfeitee todos os 


k m 
Links 

Make - contribuiçâmositiva suficiente pasatisfazer um 
Softgoal 


Design 
process be 
efectivo 


Design 
process be 
accurate 


Reuse 
previous 
designs 


Feto. hepitatar re aachen dabindes pro ?pagezistaQuickGuise 


Links w 


OR-Decomposition - O pai é satisfeito se algum dos filhos está 
satisfeito. 


antro! mare 
“aná closeout the” 
project 


Links = 


Contribution - os links de contribuição podem ser usados para ligar 
qualquer um dos elementos a um softgoal, para modelar a maneira 
que o elemento afeta a satisfação ou cumprimento do softgoal. 


Make: a contribuição é positiva o suficiente para satisfazer o 
softgoal. 


Some+: uma contribuição positiva cuja força é desconhecida. 


Help: uma contribuição positiva parcial, não é suficiente por si 
só para satisfazer o softgoal. 


Links ao 
Break - Uma contribuição negativa suficiente para negar um 
Softgoal. 
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OR-Decomposition 


Decompõe o elemento (ex: objetivo) em subelementos do 
mesmo tipo (ex: subobjetivos) de modo que, para o elemento 
ser atingido, apenas um subelemento precisa ser atingido. 


Brand meeting 


AND-Decomposition 


a 


Decompõe o elemento (ex: objetivo) em subelementos do 
mesmo tipo (ex: subobjetivos) de modo que, para o elemento 
ser atingido, todos os subelementos devem ser atingidos. Obs: 
não faz sentido decompor um elemento em apenas um 


subelemento. 


Make Contribution 


Aasieep fallen 


a 
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APÊNDICE L — CONTEÚDO DA AULA SOBRE DIRETRIZES ONTOLÓGICAS 
PARA A CRIAÇÃO DE MODELOS | 


Agenda ia 


Oque são as Diretrizes Ontológicas? 
Descrição e exemplificação das diretrizes ontológicas 


Diretrizes 
Ontológicas para 
a Criação de 
Ea Modelos i* 


Ramilton Gomes 
mn mm Renata Guizzardi 


O Que são as Diretrizes Ontológica? is hos 
* São orientações para auxiliar na escolha dos links a serem Os elementos e links de i* 
aplicados entre os elementos de um modelo i*. 
são os mes mos 


* As diretrizes são ditas ontológicas porque são baseadas no 
uso de uma ontologia como referência para sua criação, 
ainda que nesta apresentação, os detalhes da ontologia 

não sejam apresentados 


Diferenças entre Means-End e Resumo sobre o uso de 


Decomposition s = iti 
Ofink Mens. End é aplicado entre elementos distintos. Ex: Means-End x Or-decomposition 


tarefa-objetivo e recurso-tarefa. 


Ofink de decomposição é aplicado entre elementos 
idênticos. Ex: objetivo-subobjetivo, tarefa-subtarefa. 


ne 
fes | E 


Aplicação do link Means-end Aplicação do link decomposition or/and 


é 


Break Contribution 
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a 


Hurt Contribution Em resumo 


Make contribution: tarefa satisfaz 
completamente o objetivo, ainda que não tenha 
sido executada para tal; 
Break contribution: tarefa desativa outra tarefa 
que satisfaria o objetivo, negando, portanto, tal 
objetivo; 
Help contribution: tarefa satisfaz parcialmente o 


então tal tarefa hurts este último objetivo. 
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